<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
On 06/09/2016 08:52 AM, Guido van Rossum wrote:<br>
</div>
<blockquote
cite="mid:CAP7+vJJnqMEtz1oj3sQ1wB1S10kTgS7KyWPFctxp4Jf8_oHmsA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">That leaves direct calls to
os.urandom(). I don't think this should block either.<br>
</div>
</div>
</blockquote>
<br>
Then it's you and me against the rest of the world ;-)<br>
<br>
<br>
Okay, it's decided: os.urandom() must be changed for 3.5.2 to never
block on a getrandom() call. It's permissible to take advantage of
getrandom(GRND_NONBLOCK), but if it returns EAGAIN we must read from
/dev/urandom.<br>
<br>
<br>
It's already well established that this will upset the cryptography
experts. As a concession to them, I propose adding a simple!
predictable! function to Python 3.5.2: os.getrandom(). This would
be a simple wrapper over getrandom, only available on platforms that
expose it. It would provide a way to use both extant flags,
GRND_RANDOM and GRND_NONBLOCK, though possibly not exactly
mirroring the native API.<br>
<br>
This would enable cryptography libraries to easily do what (IIUC)
they regard as the "correct" thing on Linux for all supported
versions of Python:<br>
<blockquote>if hasattr(os, "getrandom"):<br>
bits = os.getrandom(n)<br>
else:<br>
bits = os.urandom(n)<br>
</blockquote>
I'm not excited about adding a new function in 3.5.2, but on the
other hand we are taking away this functionality they had in 3.5.0
and 3.5.1 so only seems fair. And the implementation of
os.getrandom() should be very straightforward, and its semantics
will mirror the native call, so I'm pretty confident we can get it
solid in a couple of days, though we might slip 3.5.2rc1 by a day or
two.<br>
<br>
Guido: do you see this as an acceptable compromise?<br>
<br>
Cryptographers: given that os.urandom() will no longer block in
3.5.2, do you want this?<br>
<br>
<br>
Pointing out an alternate approach: Marc-Andre Lemburg proposes in
issue #27279 ( <a class="moz-txt-link-freetext" href="http://bugs.python.org/issue27279">http://bugs.python.org/issue27279</a> ) that we should
add two "known best-practices" functions to get pseudo-random bits;
one merely for pseudo random bits, the other for crypto-strength
pseudo random bits. While I think this is a fine idea, the exact
spelling, semantics, and per-platform implementation of these
functions is far from settled, and nobody is proposing that we do
something like that for 3.5.<br>
<br>
<br>
<i>/arry</i><br>
</body>
</html>