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

[Donald Stufft]

> On Jun 9, 2016, at 1:21 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> On 9 June 2016 at 17:54, Ben Leslie <benno at benno.id.au> wrote:
>>> My opinion is that blocking is slightly better than raising an exception because it matches what other OSs do, but that both blocking and raising an exception is better than silently giving data that may or may not be cryptographically secure.
>> 
>> I think an exception is much easier for a user to deal with from a
>> practical point of view. Trying to work out why a process has hung is
>> obviously possible, but not necessarily easy.
> 
> If we put the specific issue of applications that run very early in
> system startup to one side, is there a possibility of running out of
> entropy during normal system use? Even for a tiny duration? An
> exception may be better than a hanging process, but a random process
> crash in place of a wait of a few microseconds for the entropy buffer
> to fill up again not so much.
> 
> If we could predict whether the call was going to block for a
> microsecond, or for 20 minutes, I'd be OK with an exception for the
> latter case. But we can't predict the future, so unless the system
> call is guaranteed not to block except at system startup, then I
> prefer blocking over an exception.

/dev/urandom (and getrandom() on Linux) will never block once the pool
has been initialized. The concept of “running out of entropy” doesn’t
apply to it. Once it has entropy it’s good to go.

> 
> As for blocking vs returning less random results, I defer to others on that.
> 
> On 9 June 2016 at 18:14, Steven D'Aprano <steve at pearwood.info> wrote:
>> On Thu, Jun 09, 2016 at 12:39:00PM -0400, Donald Stufft wrote:
>> 
>>> There are three options for what do with os.urandom by default:
>>> 
>>> * Allow it to silently return data that may or may not be
>>> cryptographically secure based on what the state of the urandom pool
>>> initialization looks like.
>> 
>> Just to be clear, this is only an option on Linux, right? All the other
>> major platforms block, whatever we decide to do on Linux. Including
>> Windows?
> 
> That's what I understood, certainly. But the place where this was an
> issue in real life was a Python program being run during the startup
> sequence of the OS. That's never going to be possible on Windows, so
> I'd be cautious about drawing parallels with Windows in this situation
> (blocking on Windows may be fine because Python can never run when
> Windows could possibly have low entropy available).
> 
> Paul


—
Donald Stufft