Hash unstable across executions

[orlitzky]

Hello, I see that the docs already say that the hash is not necessarily stable across library versions, architectures, etc. And that there's a build flag to randomize the seed every time an executable is run. Can we infer that hashes should not be treated as stable between two (chronologically proximal) runs of the same program?

[phadej]

And that there's a build flag to randomize the seed every time an executable is run

That flag is intended to be used for testing purposes only.

There is code which relies on fact that hash results don't change on each run. (E.g. template haskell Lift (HashMap k v) instance, or using compact regions).

I probably should add a big warning mentioning that use case.

But we might introduce some compilation time seed randomization, if I figure out how to do that cleanly.

[orlitzky]

Ok, thank you. Hakyll is using a hash to determine which parts of your website need to be rebuilt, and that doesn't seem unreasonable to me. But, our distro package enables the random seed. So I wanted to be sure before I went hacking on the distro package.

[phadej]

Which distro does so? That's wrong and you have my blessing to yell on the packagers for your distribution.

In particular, random-initial-seed is not a security feature.

If they don't listen, I have no other way forward then to remove the flag.

[orlitzky]

Gentoo, but I think the change was well-intentioned. I have commit access so there shouldn't be much of a struggle :)

[orlitzky]

If you want to add a big warning to the docs I think it might help, but I've updated the Gentoo package so for me the issue is resolved. Thanks for your help.

[hololeap]

I was the one who turned it on in Gentoo, and it was only to catch packages that relied on the hash being stable, just so we might prevent strange bugs from appearing in the future. @orlitzky turned it off again and I have no problem with that. I didn't know about hakyll and others relying on the hashes not changing between runs.