fetchurl: better support multiple hash types #15441
Conversation
Instead of requiring that Nix be new enough to handle the sha512 hash type if it is passed to fetchurl with an assert, instead fallback to other hash types if Nix is not new enough. This enables passing multiple hash types (e.g. sha256 and sha512) to fetchurl in a way that can be evaluated on both new and old Nixes that do/do not support the newer hash (sha512). See conversation at NixOS#15048.
|
By analyzing the blame information on this pull request, we identified @edolstra, @domenkozar and @urkud to be potential reviewers |
|
I added a commit that gives util-linux both sha512 and sha256 hashes, and it seems to evaluate with both Nix 1.10 and Nix 1.11.2. Further testing would be appreciated to make sure this works properly with both old and new Nix versions. |
|
+1 for reverting to sha256 in util-linux (your 2nd commit). I'm less sure about the 1st commit. As long as nix will rebuild when changing hash type (that's unfortunate!), I think there is little value in allowing sha512 for newer nix, because old nix users cannot use the binaries produced by the new nix (they have to build it themself, as @vcunat pointed out in #15048 (comment)). Due to it being a mass-rebuild (!), I'd like to defer to others to decide whether to merge (the util-linux commit) to staging or master. |
|
What's our story for upgrading to newer hashes? Being stuck on sha256 forever is not something that I'm OK with; we need to have cryptographic agility to be able to update to newer, stronger hashes over time. Maybe this will require some changes to Nix itself, or maybe we should have a policy about how long to wait for a newer Nix version to disseminate (1 major NixOS version?) before bumping the minimum required version, but IMO it's important that we find a story for this that preserves backwards compatibility. Personally, I use a number of tweaks that mean I have to recompile everything anyways, so I don't mind. Another point is that I'm assuming Hydra has a new Nix and will use sha512 for the binary cache, so only users with old Nix versions will need to recompile; this may be a good incentive to have them upgrade sooner rather than later. Also note that the second commit has both sha512 and sha256, so without the first commit fetchurl will always try to use sha512, but will throw an assert if Nix is too old. |
|
Also, I don't see why this is a mass-rebuild; this just causes fetchurl to skip looking at sha512 if Nix is too old, and the only package that this would affect is util-linux with the second commit, which can now be evaluate on old Nix instead of simply throwing an assert. |
|
Oh, right, it isn't mass-rebuild (I thought it did s/sha512/sha256/, but it really adds sha256). But how important is it to have sha512 now, as opposed to waiting one more release cycle (6 months)? I'm asking seriously, I don't know what kind of risk it poses. Another possibility, IMHO, would be to backport sha512 support to Nix 1.10, the version used on NixOS 15.09. Anyway, I'm not against this patch. I just said I was unsure about the 1st commit, as I explained above. |
|
I didn't follow this discussion and staged 26e8e3e for now, with the glibc security rebuild. I think the main incentive for sha512 was changes in Mozilla's releases NixOS/nix#679 that made getting other hashes from them more difficult. |
|
@bjornfor @vcunat How do you feel about this PR now? It's one release cycle later (16.09 is almost here), more packages are using sha512 (see #16391 for example), and makes it easier to move from |
|
Hm, I'd like to back out of this discussion. I'll leave the decision whether this is the right approach to more skillful / knowledgeable Nix'ers. |
|
@grahamc security, enhancement |
|
Another release cycle is up soon, so this workaround shouldn't be needed (everyone should be running a recent enough Nix soon). Plus, the fact that evaluating the same packages on different Nix version sounds highly undesirable. Closing. |
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)Instead of requiring that Nix be new enough to handle the sha512 hash
type if it is passed to fetchurl with an assert, instead fallback to
other hash types if Nix is not new enough. This enables passing
multiple hash types (e.g. sha256 and sha512) to fetchurl in a way that
can be evaluated on both new and old Nixes that do/do not support the
newer hash (sha512).
See conversation at #15048.
This did not cause any rebuilds for me (with Nix version 1.11.2); I did not test with an older Nix but I will try to do that soon. If this change is accepted, I would like to have future changes require both sha256 and sha512 hashes so they can evaluate on both old and new Nix versions.
cc @vcunat