Victor -

I see three options for 3.5.2:

* continue with the 3.5.1 behaviour, which blocks all python invocations in low-entropy situations. I think this is highly undesireable.

* apply my patches, which fixes the hash secret initialization but not 'import random'. This at least allows current Debian testing-track systems to boot properly ;)

* attempt to find a solution for #25420 which also addresses this issue. The original patch we submitted fixed both, but has encountered community objections from Donald and others.

The situation we're encountering is that it is *not possible* to use a sound PRNG under certain circumstances - if the system doesn't have entropy, it doesn't have entropy and there's not a lot to be done about it apart from wait.

I posit that an application which uses the random module has higher expectations of unpredictability, and therefore should take userspace measures to ensure entropy availability (as you suggest in msg253163 for example).

Note that the previous behavior (reading /dev/urandom) returns potentially unsafe data (as Donald and others point out). The only resolution to me seems to be modifying the behavior of the random module so that the buffer is initialized lazily (at first use, rather than at module import). This should be relatively straightforward, but I haven't had time to unpick all the logic of random.py to determine The Right Thing. Maybe Raymond can take a look at this?

In summary: I propose that the fix for this issue be implemented using the patches already discussed in this thread, and the fix for #25420 be implemented by modifying random.py.

Is this acceptable to everyone?