
On Jun 09 2016, Larry Hastings <larry@hastings.org> wrote:
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".
Aeh, what the tin says is "return random bytes". What everyone uses it for (including the standard library) is to provide randomness for cryptographic purposes. What it does (in the problematic case) is return something that's not random. To me this sounds about as sensible as having open('/dev/zero') return non-zero values in some rare situations. And yes, for most people "the kernel running out of zeros" makes exactly as much sense as "the kernel runs out of random data". Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«