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 / c...@tuatha.org / +353 87 2469146
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
