<p dir="ltr">Le 5 août 2016 9:42 PM, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> a écrit :<br>
> Can someone write a brief summary of the differences between the two?</p>
<p dir="ltr">Oh, it's hard to summarize. Let me try. As you may expect, my summary is far from being fair :-D</p>
<p dir="ltr">--</p>
<p dir="ltr">The two PEPs propose a very different behaviour when os.urandom() would block: raise an exception (522) or wait (524).</p>
<p dir="ltr">The PEP 522 forces developers to explicitly handle a rare case (when urandom blocks).</p>
<p dir="ltr">The PEP 524 proposes to be optimistic and hope that if urandom hangs, it doesn't hang too long.</p>
<p dir="ltr">The corner case of the corner case is when urandom blocks really too long (longer than 60 seconds, or simply forever).</p>
<p dir="ltr">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).</p>
<p dir="ltr">--</p>
<p dir="ltr">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.</p>
<p dir="ltr">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, ...).</p>
<p dir="ltr">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.</p>
<p dir="ltr">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...).</p>
<p dir="ltr">--</p>
<p dir="ltr">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).</p>
<p dir="ltr">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).</p>
<p dir="ltr">--</p>
<p dir="ltr">IMO PEP 524 has a lower impact on backward compatibility and is easier to implement.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Victor</p>