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

Larry Hastings larry at hastings.org
Sat Jun 11 17:58:07 EDT 2016

On 06/11/2016 01:48 PM, Guido van Rossum wrote:

So I still don't see why we need os.getrandom() -- it has nothing to recommend it over the secrets module (since both won't happen before 3.6).

I have two reasons, neither of which I think are necessarily all that persuasive. Don't consider this an argument--merely some observations.

First, simply as a practical matter: the secrets module is currently pure Python. ISTM that the os module is where we put miscellaneous bits of os functionality; getrandom() definitely falls into that category.
Rather than adding a new _secrets module or whatever it seemed easiest just to add it there.

Second, I'd put this under the "consenting adults" rule. Clearly cryptography is a contentious subject with sharply differing opinions.
There are many, many cryptography libraries available on PyPi; perhaps those libraries would like to use getrandom(), or /dev/urandom, or even getentropy(), in a way different than how secrets does it. My thinking is, the os module should provide platform support, the secrets module should be our codified best-practices, and we encourage everyone to use secrets. I'd go so far as to add that recommendation to the doc and the docstrings of os.urandom(), random.SystemRandom, and os.getrandom() (and os.getentropy()) if we add it. But by providing the OS functionality in a neutral way we allow external cryptographers to write what they view as best-practices code without wading into implementation detalis of secrets, or using ctypes, or whatnot.

But like I said I don't have a strong opinion. As long as we're not adding mysterious flags to os.urandom() I'll probably sit the rest of this one out.

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

More information about the Python-Dev mailing list