[Security-sig] Take a decision for os.urandom() in Python 3.6
Donald Stufft
donald at stufft.io
Sat Aug 6 13:34:36 EDT 2016
> On Aug 6, 2016, at 1:21 PM, Guido van Rossum <guido at python.org> wrote:
>
>
> There is one thing that is still really unresolved for me, and that is
> a good understanding of how likely this feared event, "not having
> enough entropy" actually is, for environments where Python may
> actually be used. My main question is, can it occur in situations
> *other* than during very early startup? What's the answer for various
> platforms? Once I'm past this boot phase, can I safely assume
> os.urandom() will never block, or is there still a possibility for a
> system to run out of entropy later (say, by excessive calls to
> os.urandom(), possibly in another process)? The text of
> https://www.python.org/dev/peps/pep-0522/#adding-secrets-wait-for-system-rng
> suggests that that is *not* a possibility (since it recommends putting
> that call in __main__).
>
> Anyways, if the answer ends up being "yes, some systems may
> occasionally run out of entropy during normal operation", I would
> count that as a further point against PEP 522.
For all of the major platforms that I can think of, once os.urandom is out of
this early boot phase it will never block (or it will never block ever on
that platform). This covers:
* Linux
* Windows
* OS X
* FreeBSD
* OpenBSD
* Solaris (I think)
I have no idea what more obscure platforms like AIX do, I suspect they’ll behave
like older Linux though, where /dev/urandom will never block and might give bad
data. This means that once you’ve gotten any data from a urandom that could possibly
block, it will never block. I could be wrong though.
Essentially, you’re waiting for the device to be fully initialized, and once it
is initialized it is initialized, it will never revert to an “uninitialized”
state.
This has a side effect that if someone wanted to say, ensure that os.urandom was
non-blocking before binding to a port with an asyncio daemon they could simply call
``os.urandom(1)`` which will either return immediately if the urandom device is
already initialized or block until it is initialized.
> But, assuming I am asked for a vote, my vote goes to Victor's PEP 524,
> making os.urandom() occasionally block even on Linux, and adding
> os.getrandom() on those platforms that have it.
>
I agree, though I’m neutral on os.getrandom.
—
Donald Stufft
More information about the Security-SIG
mailing list