Here's where things stand, as I currently see it.

Under certain circumstances, under Linux at least, calls to getrandom() will block. Specifically, they will block if the system's PRNG has been insufficiently initialized. Depending on the nature of the host, this block can be for a long time - delays of over 90 seconds have been observed.

This does not just affect VMs; physical systems are also affected.

Even if an application does not explicitly request random data, Python calls this function early in its execution to initialize the per-process hash seed (in _PyRandom_Init()).

The net effect is that *all* invocations of Python will block at startup if the system RNG is blocking. The only reason this is being called out as Linux-specific is that the behavior has been noticed in Linux.

I posit that it's *highly undesirable* to have Python block on the system RNG even when called in non-crypto contexts. (The specific trigger for this bug is the current behavior of Debian's 'testing' branch which calls a Python script very shortly after boot to parse crontab entries.)

Regardless of what behavior is expected of module functions such as os.urandom(), a blocking RNG must not be used to initialize _Py_HashSecret, even at the expense of predictability.

I agree that ultimately a variety of interfaces should be exposed, to allow developers to choose sensible compromises between performance and security. However, the current patchset makes the minimal change to system behavior while allowing a practical path forward.

My personal preference would be for os.urandom(n) to favor non-blocking operation over cryptographic security, and either add os.random() or add an optional parameter to os.urandom() to make the opposite trade-off.

Given the deadline requested by Larry for 3.5.2, however, can I suggest that the minimal solution is the one already proposed by myself and Victor?

(Aside: "you should fix Linux" is not really within the realm of practicality.)