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

Guido van Rossum guido at python.org
Thu Jun 9 11:52:50 EDT 2016


Wow. I have to decide an issue on which lots of people I respect disagree
strongly. So no matter how I decide some of you are going to hate me. Oh
well. :-(

So let's summarize the easy part first. It seems that there is actually
agreement that for the initialization of hash randomization and for the
random module's Mersenne Twister initialization it is not worth waiting.

That leaves direct calls to os.urandom(). I don't think this should block
either.

I'm not a security expert. I'm not really an expert in anything. But I
often have a good sense for what users need or want. In this case it's
clear what users want: they don't want Python to hang waiting for random
numbers.

Take an example from asyncio. If os.urandom() could block, then an ayncio
coroutine that wants to call it would have to move that call to a separate
thread using loop.run_in_executor() and await the resulting Future, just to
avoid blocking all I/O. But you can't test such code, because in practice
when you're there to test it, it will never block anyway. So nobody will
write it that way, and everybody's code will have a subtle bug (i.e. a
coroutine may block without letting other coroutines run). And it's not
just bare calls to os.urandom() -- it's any call to library code that might
call os.urandom(). Who documents whether their library call uses
os.urandom()? It's unknowable. And therein lies madness.

The problem with security experts is that they're always right when they
say you shouldn't do something. The only truly secure computer is one
that's disconnected and buried 6 feet under the ground. There's always a
scenario through which an attacker could exploit a certain behavior. And
there's always the possibility that the computer that's thus compromised is
guarding a list of Chinese dissidents, or a million credit card numbers, or
the key Apple uses to sign iPhone apps. But much more likely it just has my
family photos and 100 cloned GitHub projects.

And the only time when os.urandom() is going to block on me is probably
when I'm rebooting a development VM and wondering why it's so slow.

Maybe we can put in a warning when getrandom(..., GRND_NONBLOCK) returns
EAGAIN? And then award a prize to people who can make it print that
warning. Maybe we'll find a way to actually test this code.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160609/cfb39b3d/attachment.html>


More information about the Python-Dev mailing list