On Sat, Jun 11, 2016 at 2:16 PM, Donald Stufft <donald@stufft.io> wrote:

On Jun 11, 2016, at 4:48 PM, Guido van Rossum <guido@python.org> wrote:

But I find an os.getrandom() that only exists on those (few?) platforms that support it a nuisance too -- this just encourages cargo cult code that's unnecessarily complicated and believed to be secure without anybody ever verifying.

Well, new enough Linux has getrandom(0), OpenBSD has getentropy(), Solaris has getrandom(), Windows has CryptGenRandom which all make it possible (or it’s the only way to invoke it) to get cryptographically secure random bytes or block and no in-between. So it’d likely be possible to have os.getrandom() with blocking semantics and no FD on all of the most popular platforms we support.

If we relax the no FD then FreeBSD and OS X also have /dev/random (or /dev/urandom it’s the same thing) which will ensure that you give cryptographically secure random bytes.

OK, so we should implement the best we can do for the secrets module, and leave os.urandom() alone. I think the requirement that the secrets module remain pure Python has to be dropped. I'm not sure what it should do if even blocking can't give it sufficiently strong random bytes, but I care much less -- it's a new API and it doesn't resemble any OS function, so as long as it is documented it should be fine.

An alternative would be to keep the secrets module linked to SystemRandom, and improve the latter. Its link with os.random() is AFAIK undocumented. Its API is clumsy but for code that needs some form of secret-ish bytes and requires platform and Python version independence it might be better than anything else. Then the secrets module is just what we recommend new users on Python 3.6.

--Guido van Rossum (python.org/~guido)