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/