[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
ethan at stoneleaf.us
Thu Jun 9 18:44:11 EDT 2016
On 06/09/2016 03:22 PM, Larry Hastings wrote:
> On 06/09/2016 08:52 AM, Guido van Rossum wrote:
>> That leaves direct calls to os.urandom(). I don't think this should
>> block either.
> Then it's you and me against the rest of the world ;-)
> 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?].
> As a concession to [the crypto experts], I propose adding a simple!
> predictable! function to Python 3.5.2: os.getrandom().
This would be unnecessary if we go the exception route.
> And the implementation of os.getrandom() should be
> very straightforward, and its semantics will mirror the native call, so
> I'm pretty confident we can get it solid in a couple of days, though we
> might slip 3.5.2rc1 by a day or two.
I would think the exception route would also not take very long to make
Okay, I'll shut up now. ;)
More information about the Python-Dev