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

[Larry Hastings]

On 06/11/2016 11:30 AM, Donald Stufft wrote:
> The problem is that someone writing software that does 
> os.urandom(block=True) or os.urandom(exception=True) which gets some 
> bytes doesn’t know if it got back cryptographically secure random 
> because Python called getrandom() or if it got back cryptographically 
> secure random because it called /dev/urandom and that gave it secure 
> random because it’s on a platform that defines that as always 
> returning secure or because it’s on Linux and the urandom pool is 
> initialized or if it got back some random bytes that are not 
> cryptographically secure because it fell back to reading /dev/urandom 
> on Linux prior to the pool being initialized.

Let me jump in tangentially to say: I think os.urandom(block=True) is 
simply a bad API.  On FreeBSD and OpenBSD, /dev/urandom may block, and 
you don't have a choice.  On OS X, /dev/urandom will never block, and 
you don't have a choice.  In Victor's initial patch where he proposed 
it, the flag was accepted on all platforms but only affected its 
behavior on Linux and possibly Solaris.  I think it's bad API design to 
have a flag that seems like it would be meaningful on multiple 
platforms, but in practice is useful only in very limited 
circumstances.  If this were old code, or behavior we inherited from the 
platform and we were making the best of a bad situation, that'd be one 
thing.  But this is a proposed new API and I definitely think we can do 
better.

As I understand the proposed semantics for os.urandom(exception=True), I 
feel it falls into the same trap though not to the same degree.

Of course, both flags break backwards-compatibility if they default to 
True, and I strongly disagree with .

It's far better in my opinion to keep the os module as a thin shell over 
platform functionality.  That makes Python's behavior more predictable 
on a platform-by-platform basis.  So I think the best approach here is 
to add os.getrandom() as a thin shell over the local getrandom() (if any).


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160611/93628969/attachment.html>