This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Colm Buckley, Lukasa, alex, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.12:36:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
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.

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

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.
Date User Action Args
2016-06-07 12:36:59lemburgsetrecipients: + lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 12:36:59lemburglinkissue26839 messages
2016-06-07 12:36:58lemburgcreate