Thanks Theodore!

Your analysis was exactly what I was aiming for when I requested a thorough security analysis in form of a PEP. The correct choice of CPRNG is important for the overall security. I'm mostly concerned with the behavior of os.urandom(), which is Python's preferred CPRNG for any critical data from session keys to key material. Several people including me have been pushing developers towards os.urandom() for many years. For that reason I put up a veto against any hasty change. Larry could my bluff.

The hash randomization for hashing of strings and bytes is explained in PEP 456, https://www.python.org/dev/peps/pep-0456 . I wrote the PEP and added DJB's and JP Aumasson's SipHash24 as PRF. The 24 byte Py_HashSecret struct contains two keys for SipHash24 and another 8 byte key for randomization of expat XML library, https://hg.python.org/cpython/file/tip/Include/pyhash.h#l34 .

For short-running scripts early in the boot phase, hash randomization is not required at all. It is only relevant for applications that reads untrusted data from potentially malicious peers. GET dict of HTTP requests is a famous example. Hash randomization can already be disabled or set to a fixed value by using an env var. I argued to add an option that falls back to a different CPRNG and sets other options at the same time (#16499) but Larry (release manager of 3.5) is against any option. He wants Python to always start in a timely fashion without any extra arguments.

Your suggestion should fix the issue on Linux (GRND_NONBLOCK, fall back to srandom()), although I would rather use gettimeofday() with t.tv_sec + t.tv_usec. I'm still concerned how we should address the issue on BSD. As far as I am familiar with BSD, all reads from the Kernel's CPRNG are blocking until the CPRNG is seeded.

I can bring up the issue with Lennart, if it is really necessary (one advantage of working for Red Hat ;) ). I'm going to ping JP Aumasson to get his feedback.