Message 267993 - Python tracker (original) (raw)

Can we please try to be clear about what kind of blocking we mean? getrandom(flags=0) absolutely can block: that's what the original issue was all about. To ensure it never blocks you need to call getrandom(GRND_NONBLOCK): that's why the flag exists.

Thanks, I was actually confused on this issue. I thought CPython was using getrandom(GRND_RANDOM) and that's why it was blocking. But to be clear, you're right: 3.5.1 is calling getrandom(0) in all circumstances. It never passes in GRND_RANDOM and it never passes in GRND_NOBLOCK. And according to the manpage for getrandom(), getrandom(0) "blocks if the entropy pool has not yet been initialized".

What I don't understand is this, from the manpage for urandom:

A read from the /dev/urandom device will not block waiting for more entropy. If there is not sufficient entropy, a pseudorandom number generator is used to create the requested bytes.

If both sources are right, then /dev/urandom behaves quite differently from getrandom(0).

Imagine how confused I was when Theodore Ts'o said:

First of all, if you are OK with reading from /dev/urandom, then you might as well use getrandom's GRND_NONBLOCK flag. They are logically equivalent.

He wrote it. But what he said there doesn't jibe with what the manpages say. Those say that if you call getrandom(GRND_NONBLOCK) before the entropy pool has been initialized, it will return EAGAIN, but any time you read from /dev/urandom you will always get random data.

... the more I learn about this, the less I think I understand it.