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.11:51:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> That's pretty much in line with what the implementation now does.

Literally the first line of the os.urandom documentation is "Return a string of n random bytes suitable for cryptographic use.". There is absolutely a promise that, as long as your OS isn't broken, this will provide cryptographically safe random numbers. As Cory pointed out, random.SystemRandom and the new secrets module are both relying on this promise of cryptographically safe numbers to provide their functionality, as is a number of other, external Python programs.

This patch is a regression in the safety of this function, flat out, no way around it.

Modern *nix's other than Linux have all already made /dev/urandom blocking on start up until it's been intialized. The only reason Linux hasn't is because Ted T'so has bad opinions, but that doesn't change the fact that people should always use urandom, and you should block until it's been initialized.

I fail to understand why, if the CPython start up needs non blocking random to the point it would rather have cryptographically unsafe random than block, why a function that does that shouldn't be added instead of causing every other use of ``os.urandom`` to be potentially unsafe.
Date User Action Args
2016-06-07 11:51:54dstufftsetrecipients: + dstufft, lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 11:51:54dstufftsetmessageid: <>
2016-06-07 11:51:54dstufftlinkissue26839 messages
2016-06-07 11:51:53dstufftcreate