This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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