On 2021-11-17 at 20:19:49, rsbecker@nexbridge.com wrote:
> 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.

I think in this case I'd like to try to stick with OpenSSL or other
standard interfaces if that's going to meet folks' needs.  I can write
an HMAC-DRBG, but getting entropy is the tricky part, and jitterentropy
approaches are controversial because it's not clear how unpredictable
they are.  I'm also specifically trying to avoid anything that's
architecture specific like RDRAND, since that means we have to carry
assembly code, and on some systems RDRAND is broken, which means that
you have to test for that and then pass the output into another CSPRNG.
I'm also not sure how maintainable such code is, since I don't think
there are many people on the list who would be familiar enough with
those algorithms to maintain it.  Plus there's always the rule, "Don't
write your own crypto."

Using OpenSSL or system-provided interfaces is much, much easier, it
means users can use Git in FIPS-certified environments, and it avoids us
ending up with subtly broken code in the future.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA