[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev