Disallow SRI hashes in sha256 attributes

This post is the result of a conversation as a result of a review: android-tools: 31.0.3p1 -> 33.0.3 by yu-re-ka · Pull Request #196144 · NixOS/nixpkgs · GitHub

Currently a lot of packages have a src defined like:

src = fetchurl {
    url = "...";
    sha256 = "1f2svy381r798hjinrc2xiwz13gkkqxfill343zvv8jqkn8rzxhf";
};

When updating the URL, people can use lib.fakeSha256 to invalidate the hash:

src = fetchurl {
    url = "...";
    sha256 = lib.fakeSha256;
};

Nix will in this case output the following:

error: hash mismatch in fixed-output derivation '...':
         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
            got:    sha256-jOF02reB1d69Ke0PllciMfd3vuGbjvPBZ+M9PqdnC8U=

This is confusing, as a sha256 hash was specified, but a SRI hash is mentioned in the error message. Most users will then replace their sha256 hash with the SRI one:

src = fetchurl {
    url = "...";
    sha256 = "sha256-jOF02reB1d69Ke0PllciMfd3vuGbjvPBZ+M9PqdnC8U=";
};

This doesn’t seem correct to me, but Nix does accept a SRI hash inside the sha256 attribute. I think in such cases the person making the change should then also change sha256 = to hash =:

src = fetchurl {
    url = "...";
    hash = "sha256-jOF02reB1d69Ke0PllciMfd3vuGbjvPBZ+M9PqdnC8U=";
};

Personally I’d like to see one of two things:

  • Whenever a derivation uses sha256 hash, that Nix will also output a sha256
  • Whenever a SRI hash is dropped into a sha256 attribute, that Nix will give an assertion error mentioning:
    Error: the SRI hash was used inside a sha256 attribute.  sha256 attributes should contain sha256 hashes, while SRI hashes should be used in the hash attribute. Consider rewriting:
    
      sha256 = "sha256-jOF02reB1d69Ke0PllciMfd3vuGbjvPBZ+M9PqdnC8U=";
    
    to:
    
      hash = "sha256-jOF02reB1d69Ke0PllciMfd3vuGbjvPBZ+M9PqdnC8U=";
    
  • Instead of showing an error, show an warning, to keep nixpkgs and other derivations backwards compatible.

I personally prefer eventually having the 2nd solution, but the 3rd might be a good migration step.

Is this worthy of a RFC?

I think you can file this verbatim as an issue on NixOS/nix.

1 Like

There is already RFC 131, and this is not too convincing as Nixpkgs policy, let alone as Nix breaking change.

4 Likes

You’re right. Thanks for referring me to RFC131, it has all the ideas there already and more :sweat_smile: .