RetroSearch Browse

Thu Jun 9 19:58:57 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-June/144986.html

Can we get any new function on all platforms, deferring to urandom() if getrandom() isn't there?

If the pattern is really going to be the hasattr check you posted earlier

Top-posted from my Windows Phone

-----Original Message-----
From: "Larry Hastings" <larry at hastings.org>
Sent: ‎6/‎10/‎2016 8:50
To: "python-dev at python.org" <python-dev at python.org>
Subject: Re: [Python-Dev] BDFL ruling request: should we block foreverwaiting for high-quality random bits?

On 06/09/2016 03:44 PM, Ethan Furman wrote:

On 06/09/2016 03:22 PM, Larry Hastings wrote: 

Okay, it's decided: os.urandom() must be changed for 3.5.2 to never 
block on a getrandom() call. 

One way to not block is to raise an exception.  Since this is such a rare occurrence anyway I don't see this being a problem, plus it keeps everybody mostly happy:  normal users won't see it hang, crypto-folk won't see vulnerable-from-this-cause-by-default machines, and those running Python early in the boot sequence will have something they can figure out, plus an existing knob to work around it [hashseed, I think?].

Nope, I want the old behavior back.  os.urandom() should read /dev/random if getrandom() would block.  As the British say, "it should do what it says on the tin".

/arry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160610/023543b8/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-June/144986.html below:

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