[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Ethan Furman]

On 06/09/2016 04:25 AM, Larry Hastings wrote:
>
> A problem has surfaced just this week in 3.5.1.  Obviously this is a
> good time to fix it for 3.5.2.  But there's a big argument over what is
> "broken" and what is an appropriate "fix".

Having read the thread thus far, here is my take on fixing it:

- Modify os.urandom() to raise an exception instead of blocking.
   Everyone seems to agree that this is a rare corner case, and
   being rare it would be easier (at least for me) to troubleshoot
   an exception instead of a VM (or whatever) hanging and then being
   killed.

- Add a CLI knob to not raise, but instead wait for initialization.
   I think this should be under the control of the user, who knows
   (or should) the environment that Python is running under, and not
   the developer who may have never dreamed his/her little script
   would be called first thing during bootup.  Maybe we just continue
   to use the hash seed parameter for this.

- Modify the functions that don't need cryptographically strong random
   bits to use the old style (reading directly from /dev/urandom?).

This seems like it should appease the security folks, yet still allow 
those in the trenches to (more) easily diagnose and work around the problem.

--
~Ethan~