Donald Stufft added the comment: > 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). ---------- _______________________________________ 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
