Home Original page

[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Larry Hastings larry at hastings.org
Thu Jun 9 23:11:08 EDT 2016 
On 06/09/2016 07:58 PM, Nathaniel Smith wrote:
> 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.

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.

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.

I don't think we should change os.urandom() to block on Linux even in 
3.6.  Happily, that's no longer my fight, as I'm not 3.6 RM.


> Would it be acceptable for 3.5.2 to start raising a warning "urandom
> returning non-random bytes -- in 3.6 this will be an error", and then
> make it an error in 3.6?

No.  In 3.5.2 and the remaining 3.5 releases, os.urandom() must behave 
identically to how it behaved in 3.4 and the previous releases.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160609/76d83e49/attachment-0001.html>
More information about the Python-Dev mailing list