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.