fetchgit: add SRI hash support

[jtojnar]

Motivation for this change

Sync fetchgit's hash support with fetchurl's to add support for SRI hashes (introduced in 267c8d6).

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[edolstra]

This should be called narHash for consistency with builtins.fetchX (NixOS/nix@d4df99a).

[jtojnar]

Should I rename it in 267c8d6 as well?

[edolstra]

Yes, probably. We could also rename everything to hash, but that's ambiguous in functions that take both a file and a NAR hash...

[jtojnar]

Does it make sense to call it narHash if it can also be used for outputHashMode = "flat"? If I understand the docs correctly, hash of the NAR is only used for FOD when using recursive output hash mode.

[jtojnar]

functions that take both a file and a NAR hash

I am not sure what you mean.

[jtojnar]

Alternately, we could use outputHash directly, as that is what gets passed to Nix in the end.

[jtojnar]

Since we are using SRI hashes, using integrity attribute name like in HTML might actually fit even better.

[jtojnar]

Until the attribute name issue is clarified, I cherry-picked the fetchpatch issue into #81564 since it is very annoying.

[worldofpeace]

cc @edolstra

I think it's really important we decide what the attribute for #79987 (comment) is going to be. There's already some stigma on base64 encoding and sri in nixpkgs #89423 #89423 and this is awfully difficult, for example, to explain to people that they can't use hash in fetchFromGitHub correctly because if they set fetchSubmodules = true the fetcher will be fetchgit which doesn't support hash yet...

[edolstra]

narHash is probably best. hash can be misunderstood as a commit hash, and integrity doesn't say whether it's a NAR hash or a flat file hash.

[jtojnar]

@edolstra What attribute will we use for flat files then?

And why do we need to distinguish between NAR hash and flat file hash by the checksum attribute? It could just be hidden inside the fetch functions and switched through outputHashMode as before.

[edolstra]

Flat file hashes are used in many places, e.g. fetchurl.

[jtojnar]

@edolstra I meant what attribute would we use for flat file hashes if we want to distinguish them from NAR hashes. fechurl currently uses sha256 for both and used a separate recursiveHash attribute as a switch between the two outputHashModes. So it does not say whether it's a NAR hash or a flat file hash any more that integrity would.

[kira-bruneau]

I agree with @jtojnar. Choosing between a file hash or a NAR hash seems like more of an implementation detail of the fetcher, rather than something that always needs to be specified by the package maintainer. I think if we required maintainers to declare it explicitly, it would cause a lot of confusion, especially for beginners.

For example, this would use a file hash:

fetchurl {
  url = "https://releases.nixos.org/nix/nix-2.3.10/install";
  hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
}

But this would require a NAR hash:

fetchurl {
  url = "https://releases.nixos.org/nix/nix-2.3.10/install";
  executable = true;
  narHash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
}

[stale]

I marked this as stale due to inactivity. → More info

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/is-it-ok-to-ask-for-hash-attribute-and-sri-hash-when-reviewing-prs-that-update-packages/20493/3

[Artturin]

support for hashes added in 5c2b1b6