Message267654
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. |
|
Date |
User |
Action |
Args |
2016-06-07 12:36:59 | lemburg | set | recipients:
+ 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:59 | lemburg | link | issue26839 messages |
2016-06-07 12:36:58 | lemburg | create | |
|