On November 16, 2021 5:18 PM, brian m. carlson wrote:

On 2021-11-16 at 15:44:33, Jeff King wrote:

quoted

On Tue, Nov 16, 2021 at 03:35:40AM +0000, brian m. carlson wrote:

quoted

For those who are interested, I computed the probability of spurious
failure for the self-test mode like so:

  256 * (255/256)^65536

This Ruby one-liner estimates the probability at approximately 10^-108:

  ruby -e 'a = 255 ** 65536; b = 256 ** 65536; puts b.to_s.length -

a.to_s.length - 3'

quoted

quoted

If I have made an error in the calculation, please do feel free to
point it out.

Yes, I think your math is correct there.

A more interesting question is whether generating 64k of PRNG bytes
per test run is going to a problem for system entropy pools. For that
matter, I guess the use of it for tempfiles will produce a similar
burden, since we run so many commands. My understanding is that

modern

quoted

systems will just produce infinite output for /dev/urandom, etc, but I
wonder if there are any systems left where that is not true (because
they have a misguided notion that they need to stir in more "real"
entropy bits).

I have specifically avoided invoking any sort of potentially blocking CSPRNG
for that reason.  /dev/urandom is specifically not supposed to block, and on
the systems that I mentioned, the way Go uses it would indicate that it
should not.  There is a system, which is Plan 9, where Go uses /dev/random
to seed an X.917 generator, and there I assume there is no /dev/urandom,
but I also know full well that we are likely completely broken on Plan 9
already, so this will be the least of the required fixes.

RtlGenRandom is non-blocking, and as the commit message mentioned,
arc4random uses ChaCha20 in a non-blocking way on all systems I could find,
except MirBSD which uses RC4, also without blocking.  Linux's CSPRNG is also
non-blocking.

I've also looked at Rust's getrandom crate, which provides support for
various other systems, and I have no indication that any of the interfaces I've
provided are blocking in any way, since that crate would not desire that
behavior.  Looking at it just now, I did notice that macOS supports
getentropy, so if I need to do a reroll, I'll add an option for that.

So I don't think we're likely to run into a problem here.  If we do run into
systems with that problem, we can add an option to use libbsd, which
provides arc4random and company (using ChaCha20).  The tricky part is that
when using libbsd, arc4random is not in <stdlib.h> (since that's a system
header file) and is instead in <bsd/stdlib.h>.  However, it's an easy change if
we run into some uncommon system where that's the case.

If we don't like the test, we can avoid running it by default on the risk of
seeing breakage go uncaught.

Adding these dependencies are also a problem. libbsd does not port to NonStop. GO is not available yet. Please stay at least somewhat POSIX-like. Begging because I do not want to lose git.
-Randall