[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