Message 267807 - Python tracker

Message267807

Author larry
Recipients Colm Buckley, Lukasa, Theodore Tso, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-08.08:38:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465375127.41.0.962205627216.issue26839@psf.upfronthosting.co.za>
In-reply-to
Content
So, in short, you don't know.

#25003 is about Solaris, and the reporter clearly had the expectation that /dev/urandom would never block.  The documentation on Linux is clear: /dev/urandom will never block.  That's two.

This "StackExchange" discussion:
  http://security.stackexchange.com/questions/42952/how-can-i-measure-and-increase-entropy-on-mac-os-x
suggests that the Yarrow-based /dev/random and /dev/urandom on OS X will *both* degrade to PRNG if insufficient entropy is present.  Thus they are are *both* like /dev/urandom, and *neither* will ever block.

The salient quote is this, from the random(4) manpage on OS X:
"If the SecurityServer system daemon fails for any reason, output quality will suffer over time without any explicit indication from the random device itself."

That sure sounds like bad quality PRNG random bits to me.  So that's three.

Again: ISTM that the universal expectation is that /dev/urandom will never block.  Therefore os.urandom() should also never block.  That it blocks in 3.5.0 and 3.5.1 is a performance regression and should be fixed.
History
Date User Action Args
2016-06-08 08:38:47larrysetrecipients: + larry, lemburg, rhettinger, doko, vstinner, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley, Theodore Tso
2016-06-08 08:38:47larrysetmessageid: <1465375127.41.0.962205627216.issue26839@psf.upfronthosting.co.za>
2016-06-08 08:38:47larrylinkissue26839 messages
2016-06-08 08:38:47larrycreate