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

[Larry Hastings]

On 06/16/2016 01:03 AM, Barry Warsaw wrote:
> *If* we can guarantee that os.urandom() will never block or raise an exception
> when only poor entropy is available, then it may be indeed indistinguishably
> backward compatible for most if not all cases.

I stepped through the code that shipped in 3.5.2rc1.  It only ever calls 
getrandom() with the GRND_NONBLOCK flag.  If getrandom() returns -1 and 
errno is EAGAIN it falls back to /dev/urandom--I actually simulated this 
condition in gdb and watched it open /dev/urandom.  I didn't see any 
code for raising an exception or blocking when only poor entropy is 
available.

As Robert Collins points out, this does change the behavior 
ever-so-slightly from 3.4; if urandom is initialized, and the kernel has 
the getrandom system call, getrandom() will give us the bytes we asked 
for and we won't open and read from /dev/urandom.  In this state 
os.urandom() behaves ever-so-slightly differently:

  * os.urandom() will now work in chroot environments where /dev/urandom
    doesn't exist.
  * If Python runs in a chroot environment with a fake /dev/urandom,
    we'll ignore that and use the kernel's urandom device.
  * If the sysadmin changed what the systemwide /dev/urandom points to,
    we'll ignore that and use the kernel's urandom device.

But os.urandom() is documented as calling getrandom() when available in 
3.5... though doesn't detail how it calls it or what it uses the result 
for.  Anyway, I feel these differences were minor, and covered by the 
documented change in 3.5, so I thought it was reasonable and un-broken.

If this isn't backwards-compatible enough to suit you, please speak up now!


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160616/831d8cdf/attachment.html>