-
-
Notifications
You must be signed in to change notification settings - Fork 15.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove sri hashes #89308
Remove sri hashes #89308
Conversation
Lowest release with SRI support is 2.2 (Jan 2019), if I look right, which is not that long. Perhaps Another issue is how to maintain the state; my suggestion: NixOS/ofborg#513 |
@@ -146,7 +146,7 @@ let | |||
else | |||
pkgs.fetchurl { | |||
url = predictURLFromPypi { inherit pname file hash kind; }; | |||
inherit hash; | |||
sha256 = builtins.elemAt (builtins.match "sha256:(.*)" hash) 0; # nix 2.0 backwards compatibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we go this route, poetry2nix should probably be updated to handle this properly.
/cc @adisbladis
Would it be worth also removing these from the release-20.03 branch as well? |
IMHO yes. |
Yeah, but I'm working a followup for base64 hashes first. |
@vcunat I disagree. I think in the past our rule was it should be possible to evaluate Nixpkgs using the Nix version from the previous NixOS release. So using SRI hashes is fine. |
🤔 oh, in terms of NixOS release support cycles it is a relatively long time now. Last default nix < 2.2 was in 18.09, which has been unsupported for over a year now. |
What's the final takeaway here? Should we allow SRI hashes in master now? Base64? And to clarify, the right format is this, right? hash = "sha256-rJbpoPjNMlw4diWjwNQ/DPo3rltvISU4kuRqBbvlBZ0="; |
Master requires nix 2.2 now so using SRI hashes there is fine. |
Sounds good. Should we revert your PR to get rid of base64 hashes? I actually quite like them, as aside from being shorter they're also an external standard, unlike our homebrew base32 encoding scheme. |
The motivation for this change is to support Nix 2.1.3. In theory Nixpkgs 20.03 should have supported Nix 2.1.3 (according to `./lib/minver.nix`, but in practice it did not: NixOS#89275 However, this was fixed in: NixOS#89308 … and this change manually backports that to the `awake-20.03` branch. The above change could not be cherry-picked due to merge conflicts with frequently changing hashes.
The motivation for this change is to support Nix 2.1.3. In theory Nixpkgs 20.03 should have supported Nix 2.1.3 (according to `./lib/minver.nix`, but in practice it did not: NixOS#89275 However, this was fixed in: NixOS#89308 … and this change manually backports that to the `awake-20.03` branch. The above change could not be cherry-picked due to merge conflicts with frequently changing hashes.
source for the quote is at NixOS#89308 (comment) edolstra> ... I think in the past our rule was it should be possible to evaluate Nixpkgs using the Nix version from the previous NixOS release...
Motivation for this change
These break compatibility with nix 2.0, see #89275. Alternative would be to bump minvers.nix, but some of this might also be relevant for 20.03 and 19.09.
Things done
Validated using
nix-env -qa --out-path -f.
with new hash types disabled.sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)