Christian Heimes added the comment: On 2016-06-09 10:49, Marc-Andre Lemburg wrote: > It is a corner case, but one we'll see hit us more often going > forward, since booting up VMs/containers no longer is a rather > rare incident. It's being used as part of the architecture of > system nowadays.
Containers are not a problem. By definition they share the Kernel with the host and therefore use the CPRNG of the host. For early boot and VM Python needs to address the problem. Neither Py_HashSecret nor the init vector of random's MT need strong cryptographic keys. Python can ask the kernel if it has initialized its RNG and then fall back to a different RNG source (e.g. srandom(3) / random(3)). For os.urandom() let's define it as non-blocking and raise an exception when it would blocks. We can safely assume that the Kernel will never block reads from its entropy source once the entropy source has been initialized. Like Py_HashSecret we can ask the Kernel for its state (on Linux: use non-blocking getrandom()). The design is simple, secure and well specified. Python's startup works under all circumstancesm os.urandom() either succeeds or fails properly and 'import random' never blocks. Christian ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27266> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
