<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 9, 2016 at 8:11 PM, Larry Hastings <span dir="ltr"><<a href="mailto:larry@hastings.org" target="_blank">larry@hastings.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div><br>
On 06/09/2016 07:58 PM, Nathaniel Smith wrote:<br>
</div>
<blockquote type="cite">
<pre>I suspect the crypto folks would be okay with pushing this back to
3.6, so long as the final resolution is that os.urandom remains the
standard interface for, as the docstring says, "Return[ing] a string
of n random bytes suitable for cryptographic use" using the
OS-recommended method, and they don't have to go change all their
code.
</pre>
</blockquote>
<br></span>
The Linux core devs didn't like the behavior of /dev/urandom. But
they couldn't change its behavior without breaking userspace code.
Linux takes backwards-compatibility very seriously, so they left
/dev/urandom exactly the way it was and added new functionality (the
getrandom() system call) that had the semantics they felt were best.<br>
<br>
I don't understand why so many people seem to think it's okay to
break old code in new versions of Python, when Python's history has
shown a similarly strong commitment to backwards-compatibility.
os.urandom() was added in Python 2.4, in 2004, and remained
unchanged for about thirteen years. That's thirteen years of people
calling it and assuming its semantics were identical to the local
"urandom" man page, which was correct.<br></div></blockquote><div><br></div><div>I can only speak for myself, but the the reason it doesn't bother me is that the documentation for os.urandom has always been very clear that it is an abstraction over multiple OS-specific sources of cryptographic randomness -- even in the 2.4 docs [1] we read that its output "depends on the OS implementation", and that it might be /dev/urandom, it might be CryptGenRandom, and it might even raise an exception if "a randomness source is not found". So as a user I've always expected that it will make a best-effort attempt to use whatever the best source of cryptographic randomness is in a given environment, or else make a best-effort attempt to raise an error if it's determined that it can't give me cryptographic randomness, and it's been doing that unchanged for thirteen years too.<br><br>But now Linux has moved forward and provided an improved OS-specific source of cryptographic randomness, and in particular one that actually signals to userspace when it doesn't have randomness available. So we have a choice: either we have to break the guarantee that os.urandom is identical to /dev/urandom, or we have to break the guarantee that os.urandom uses the best OS-specific source of cryptographic randomness. Either way we're breaking some guarantee we used to make. And AFAICT so far 100% of the people who actually maintain libraries that call os.urandom are asking python-dev to break the identical-to-/dev/urandom guarantee and preserve the uses-the-best-OS-specific-cryptographic-randomness guarantee. Disrupting working code is a bad thing, but in the long run, no-one is actually asking for an os.urandom that silently falls back on the xkcd #221 PRNG [2].<br><br></div><div>All that said, on the eve of the 3.5.2 release is a terrible time to be trying to decide this, and it makes perfect sense to me that maybe 3.5 should kick this can down the road. Your efforts as RM are appreciated and I'm glad I'm not in your spot :-).<br></div><div><br></div><div>-n<br><br>[1] <a href="https://docs.python.org/2.4/lib/os-miscfunc.html">https://docs.python.org/2.4/lib/os-miscfunc.html</a><br>[2] <a href="https://xkcd.com/221/">https://xkcd.com/221/</a><br><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Nathaniel J. Smith -- <a href="http://vorpus.org" target="_blank">https://vorpus.org</a></div></div></div>
</div></div>