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 dstufft
Recipients Colm Buckley, Lukasa, alex, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.20:07:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465330055.56.0.28219766868.issue26839@psf.upfronthosting.co.za>
In-reply-to
Content
> Once this has been done, it will never block again, and happily send you poor random data if the entropy pool has been completely wiped of any entropy data - without telling you.

This doesn't actually happen in real life, once urandom has been initialized you will never be able to get "poor random" out of it. You will get cryptographically secure random out of it always. *ACTUAL* Cryptographers pretty much universally agree on this statement. You can even use them for cryptographic keys, no matter how long it's been since your system booted as long as the urandom pool has had a chance to initialize.

> Or put differently: Where is the attack vector that blocking behavior of 
os.urandom() would help remedy ?

Someone attempting to use cryptographic random before the urandom pool has been sufficiently initialized to provide said random.
History
Date User Action Args
2016-06-07 20:07:35dstufftsetrecipients: + dstufft, lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 20:07:35dstufftsetmessageid: <1465330055.56.0.28219766868.issue26839@psf.upfronthosting.co.za>
2016-06-07 20:07:35dstufftlinkissue26839 messages
2016-06-07 20:07:35dstufftcreate