Builtins.path hash change?

Let me know if this is the wrong channel, would Help be more appropriate?

It seems like between nix 2.10 and 2.19, the hash of the path created by builtins.path has changed, but only if path= the output of an ordinary drv. E.g.:

builtins.path {
  name = "name";
  path = "/nix/store/bcwyhqvik6jhcklib33v6kykdl4zp9d4-bash-5.1-p8/bin/bash";
}

On 2.10.3 I get /nix/store/59khc904ibx2wbb0nl8yx8cacwi2jkq4-name, on 2.19.3 I get /nix/store/nj8cpsr0hz8pfl45y2jg4mzyk48h17cw-name. It doesn’t seem to happen for non-store paths, and doesn’t seem to happen for paths created via ./file refs (inherently trusted? I forget what the internal name is for those), it seems to be specific to ordinary IA drv outputs.

Is this known and expected? If so, I won’t bother to find out where exactly it happened. I didn’t see anything in release notes about hash changes, but I don’t know if there’s any obligation to document them. I’m sure devs try to avoid them but maybe builtins.path is considered a dangerous internal function to use at your own risk?

It’s not a serious problem, just a bit alarming because it makes me worry what else has changed about hashes.

This looks pretty much like a regression. Store paths should not change. Please check the issue tracker whether this was filled already, and file it if not.

Ok, filed an issue at builtins.path hash changed on IA drv output, between 2.18 and 2.19 · Issue #9946 · NixOS/nix · GitHub

I was able to try versions up to 2.18, but 2.19 and 2.20 are not in our nixpkgs latest snapshot. We are testing a locally compiled 2.19, but it’s directly from 91e60868bd1499cdf66d6a5e4edec380b1a5719f so the only difference would be 3rd party library versions, which shouldn’t affect hashes.

1 Like