[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)
Ethan Furman ethan at stoneleaf.us
Thu Jun 9 12:03:46 EDT 2016
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]