Message 267654 - Python tracker (original) (raw)

On 07.06.2016 14:19, Donald Stufft wrote:

Note how the documentation emphasizes on os.urandom() not blocking.

That line about not-blocking was added by the patch that Victor committed that we're objecting to.

Ah, sorry, I was looking at the online docs and the selector was set to 3.5.1, so I was under the impression of looking at the 3.5.1 docs, not a later version.

In any case, the point still stands: os.urandom() has always been documented as interface to /dev/urandom on Linux, which again is defined as non-blocking interface. The change in 3.5.0 to use getrandom() broke this and Victor's patch restored the previously documented and expected behavior, so I don't see what the problem is.

People looking for a blocking random number source should use /dev/random (or better: a hardware entropy device). Even with initialized entropy pool, /dev/urandom will happily return pseudo random numbers if the entropy pool lacks entropy, so you don't really win much:

""" 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. """ http://man7.org/linux/man-pages/man4/random.4.html

It's simply the wrong source to use for crypto random data, since you can never be sure that the data returned by /dev/urandom originates from true entropy or some approximation.

In that light, using it to seed hash randomization is the right approach, since you don't need a crypto RNG to seed this part of the Python runtime.