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, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.15:32:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>

This is an amusing concept, but membership in the PSRT does not empower you with a "veto".

On the other hand, being Release Manager does give me some say here.

>  You wouldn't add a workaround for broken CPU instructions to math.c or semi-functional network card to socket.c, would you?

Well, yes, of course we would, if we had to.  Consider the F00F bug.  Happily the operating systems handled that one for us.

It is unreasonable for Python startup to take 90 seconds, poorly-configured cloud virtual machine or otherwise.  And there are many, many uses of the random module and hashlib that don't require CPRNG.

On the other hand, people who need cryptographic-strength random bits should be able to get them.  And the documentation literally does state that os.urandom() is a source of cryptographically-suitable random bytes.

ISTM that the happy middle ground would be:
 * seed the random module with non-cryptographically-secure random bits
 * lazily seed hashlib

Am I missing something, besides the anxiety of making this sort of change four days before I tag 3.5.2 RC2?
Date User Action Args
2016-06-07 15:32:08larrysetrecipients: + larry, lemburg, rhettinger, doko, vstinner, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 15:32:08larrysetmessageid: <>
2016-06-07 15:32:08larrylinkissue26839 messages
2016-06-07 15:32:07larrycreate