On November 17, 2021 3:02 PM, Jeff King wrote: > On Tue, Nov 16, 2021 at 07:36:51PM -0800, Carlo Arenas wrote: > > > > > for the little amount of random data we need, it might be wiser to > > > > fallback to something POSIX like lrand48 which is most likely to > > > > be available, but of course your tests that consume lots of random > > > > data will need to change. > > > > > > Unfortunately that won't help. You have to seed lrand48 with > > > something, which usually means pid and/or timestamp. Which are > > > predictable to an attacker, which was the start of the whole > > > conversation. You really need _some_ source of entropy, and only the OS > can provide that. > > > > again, showing my ignorance here; but that "something" doesn't need to > > be guessable externally; ex: git add could use as seed contents from > > the file that is adding, or even better mix it up with the other > > sources as a poor man's /dev/urandom > > Those contents are still predictable. So you've made the attacker's job a little > harder (now they have to block tempfiles for, say, each tag you're going to > verify), but haven't changed the fundamental problem. > > It definitely would help in _some_ threat models, but I think we should strive > for a solution that can be explained clearly as "nobody can DoS your > tempfiles" without complicated qualifications. I missed this one... lrand48 is also not generally available. I don’t think it is even available on Windows. If we need a generalized solution, it probably needs to be abstracted in git-compat-util.h and compat/rand.[ch], so that the platform maintainers can plug in whatever decent platform randomization happens to be available, if any. We know that rand() is vulnerable, but it might be the only generally available fallback. Perhaps get the compat layer in place with a test suite that exercises the implementation before getting into the general git code base - maybe based on jitterentropy or sslrng. Agree on an interface, decide on a period of time to implement, send the word out that this needs to get done, and hope for the best. I have code that passes FIPS-140 for NonStop ia64 (-ish although not jitterentropy) and x86, and I'm happy to contribute some of this. Randall
