2 ms·

Is there any technical pathway for changing the underlying hash function? Similar to how git is kind of stuck on SHA1, what would it take to get this onto SHA51

• chriswarbo 2y ago
  I think it could be done in a backwards-compatible way, since existing hashes fit a known pattern; e.g. (silly example) store paths using SHA512 could be distinguished using prefix like 'sha512_'. One problem would be cache misses and duplication of files. I'm not completely up to date on Git's hash situation, but it seems to me like SHA256 is usable; but only for new repos. I imagine lots of existing infrastructure assumes SHA1 hashes though, and would break for silly reasons like different lengths. Relatedly, Nix has a new feature called `git-hashing` which can use Git tree hashes to validate fixed-output derivations, rather than requiring two separate hashes; e.g. the following `fetchTreeFromGitHub` function uses a single `tree` argument for a Git tree ID, rather than needing separate `rev` and `hash` arguments: { owner, repo, tree }: (pkgs.fetchFromGitHub { inherit owner repo; rev = tree; hash = builtins.convertHash { hash = tree; hashAlgo = "sha1"; toHashFormat = "sri"; }; }).overrideAttrs (_: { outputHashMode = "git"; }) Unfortunately, this git-hashing functionality only works for SHA1; so it's a good example of the infrastructure around Git not allowing us to move away from SHA1!