[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
larry at hastings.org
Sat Jun 11 15:53:36 EDT 2016
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
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev