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

Paul Moore p.f.moore at gmail.com
Thu Jun 9 13:21:32 EDT 2016

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.

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).


More information about the Python-Dev mailing list