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, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.15:39:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
>  ISTM that the happy middle ground would be:
> * seed the random module with non-cryptographically-secure random bits
> * lazily seed hashlib

I don't think it was actually hashlib that was causing the problem, but rather the initialization of SipHash, it just so happened that hashlib was the first import and thus was getting the blame. I could be wrong about that though. In any case, I think it's perfectly reasoanble to seed the random module with non-cryptographically-secure random bits and if applicable lazily seed hashlib.

I also think it's reasonable to seed SipHash with possibly non-cryptographically-secure random bits since it's likely to only be a problem early on in the boot cycle. Another option is as Colm suggestion, allowing the inverse of the old -R flag, to turn off hash seed randomization from the CLI so that scripts that run early on in the boot process can disable hash seed randomization and not require reading from urandom (assuming of course, they don't do something that explicitly calls os.urandom).
Date User Action Args
2016-06-07 15:39:12dstufftsetrecipients: + dstufft, lemburg, rhettinger, doko, vstinner, larry, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 15:39:12dstufftsetmessageid: <>
2016-06-07 15:39:12dstufftlinkissue26839 messages
2016-06-07 15:39:12dstufftcreate