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