3 ms·
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 distin
by 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!