[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)

Colm Buckley colm at tuatha.org
Thu Jun 9 10:02:53 EDT 2016

Larry Hastings wrote:

On 3.4 and before, on Linux, os.urandom() would never block, but if the

entropy pool was uninitialized it could return very-very-poor-quality random bits. On 3.5.0 and 3.5.1, on Linux, when using the getrandom() call, it will instead block for an apparently unbounded period before returning high-quality random bits.

Just a point of information here. Ted Ts'o commented on the quality of the pre-initialization bits; it's not a given that they're "very very poor quality". Even before the per-boot entropy pool is initialized, the kernel has a few sources of randomness available to it - viz: interrupt timings, RDRAND (on x86) and a little per-machine data (uname -a). If RDRAND is trusted, this is enough to provide quite significant entropy, however that's not much help to all the ARM devices out there.

The most pressing issue from my perspective is the hash randomization initialization; as there is currently nothing a script author can do to influence its behavior (except setting PYTHONHASHSEED before invocation, which might not be an option).

It should be possible, at least conceptually, for Python to be used to implement /sbin/init. This isn't currently the case on Linux with Python 3.5.1 and Linux 3.17+

For what it's worth, I do agree with Larry that os.urandom() should hew as closely as possible to the OS-specific urandom implementation. Adding an optional "blocking" boolean flag might be a useful addition for 3.6.

Colm

-- Colm Buckley / colm at tuatha.org / +353 87 2469146 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160609/73ef4ffb/attachment.html>

More information about the Python-Dev mailing list