[Security-sig] Take a decision for os.urandom() in Python 3.6

[Victor Stinner]

Le 5 août 2016 9:42 PM, "Ethan Furman" <ethan at stoneleaf.us> a écrit :
> Can someone write a brief summary of the differences between the two?

Oh, it's hard to summarize. Let me try. As you may expect, my summary is
far from being fair :-D

--

The two PEPs propose a very different behaviour when os.urandom() would
block: raise an exception (522) or wait (524).

The PEP 522 forces developers to explicitly handle a rare case (when
urandom blocks).

The PEP 524 proposes to be optimistic and hope that if urandom hangs, it
doesn't hang too long.

The corner case of the corner case is when urandom blocks really too long
(longer than 60 seconds, or simply forever).

The PEP 524 doesn't handle it (block). The PEP 522 makes the exceptional
corner case as important as the common case (urandom just blocks a few
seconds, or don't block at all).

--

Both PEPs want to make Python more secure: don't fall back on the "weak"
/dev/urandom (define weak: XXX) in os.urandom() before system urandom is
initialized.

Most differences between the two PEPs only impact applications calling
os.urandom() very early during system initialization (before system urandom
initialization) on a system with very slow entropy source or just no
entropy (VM, embeded device, ...).

The PEP 522 proposes to raise an exception on such case. It forces
developers to modify their code to decide how to handle such corner case:
wait a few seconds, switch to a weaker entropy source (and maybe log a
waning/error), etc.

The PEP 524 (mine) proposes to block. Applications don't need to be
modified. The expectation is that the kernel will be able to get enough
entropy fast enough. By the way, blocking on system urandom is not
something new, SSH has the same behaviour for example (try SSH on such VM
with no entropy...).

--

The PEP 524 proposes also to add a new function os.getrandom() for people
who understand low level stuff and security and want to enhance their
application on the low entropy case. It allows to reimplement the PEP 522
on Linux in a few lines of pure Python, so give control when urandom would
block (no black magic, just call os.getrandom(os.GRND_NOBLOCK) which raises
BlockingIOError).

The PEP 522 proposes a new function to wait for system urandom
initialization. Something similar to the PEP 524 but it requires to modify
all applications to use it (to get PEP 524 behaviour).

--

IMO PEP 524 has a lower impact on backward compatibility and is easier to
implement.

The risk of the PEP 524 is that developers start to expect that
os.urandom() will *never* block which simply cannot be implemented on all
platforms. Both PEP are specific to Linux (even if Solaris will benefit of
the same enhancement), but even just on Linux os.urandom() can still block
(don't raise the expected BlockingIOError) on Linux older than 3.17.

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20160806/7bfcb3d3/attachment.html>