Directions for arc4random

[Florian Weimer <fweimer at redhat dot com>]

I would like to resubmit my arc4random patch.

Most of the code, and the difficult-to-review parts, are for providing
fork safety even if the process is forked by a system call, and not a
call to the glibc function fork.

Rich Felker said that he'd prefer to use a proper lock for this in musl:

  <https://www.openwall.com/lists/musl/2018/07/02/5>

This would make arc4random far less scalable if one global state is
used.  But the implementation would be greatly simplified by this,
especially if we do not provide async-signal-safety for arc4random.  (If
we always lock around arc4random invocations and the entire
cryptographic operations, then I think this would detect fork misuse due
to hangs on that lock.)

I would like to know if I should resubmit my last, very complex
approach, or if I should switch to the simple, lock-based approach.

Thanks,
Florian