Remove sri hashes #89308
Remove sri hashes #89308
Conversation
LnL7
requested review from
cdepillabout,
FRidh,
infinisil,
jonringer and
thoughtpolice
as code owners
ofborg
bot
added
6.topic: GNOME
|
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.
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...
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...
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.sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)