[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)

Random832 random832 at fastmail.com
Sun Jun 12 01:49:34 EDT 2016

On Sat, Jun 11, 2016, at 22:37, Theodore Ts'o wrote:

On Fri, Jun 10, 2016 at 05:14:50PM -0400, Random832 wrote: > So, I have a question. If this "weakness" in /dev/urandom is so > unimportant to 99% of situations... why isn't there a flag that can be > passed to getrandom() to allow the same behavior?

The intention behind getrandom() is that it is intended only for cryptographic purposes.

I'm somewhat confused now because if that's the case it seems to accomplish multiple unrelated things. Why was this implemented as a system call rather than a device (or an ioctl on the existing ones)? If there's a benefit in not going through the non-atomic (and possibly resource limited) procedure of acquiring a file descriptor, reading from it, and closing it, why is that benefit not also extended to non-cryptographic users of urandom via allowing the system call to be used in that way?

Anyway, if you don't need cryptographic guarantees, you don't need getrandom(2) or getentropy(2); something like this will do just fine:

Then what's /dev/urandom for, anyway?

More information about the Python-Dev mailing list