Marc-Andre Lemburg added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
