This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients Lukasa, Theodore Tso, christian.heimes, dstufft, larry, lemburg, martin.panter, ncoghlan, vstinner
Date 2016-06-09.09:06:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <2816eb03-1d4e-4546-10a2-cf2e6581bb5f@cheimes.de>
In-reply-to <57592D81.9090308@egenix.com>
Content
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
History
Date User Action Args
2016-06-09 09:06:51christian.heimessetrecipients: + christian.heimes, lemburg, ncoghlan, vstinner, larry, martin.panter, dstufft, Lukasa, Theodore Tso
2016-06-09 09:06:51christian.heimeslinkissue27266 messages
2016-06-09 09:06:50christian.heimescreate