[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
ethan at stoneleaf.us
Thu Jun 9 12:03:46 EDT 2016
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
- 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.
More information about the Python-Dev