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

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