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?