Donald Stufft added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
