On 16 June 2016 at 10:01, David Mertz <me...@gnosis.cx> wrote: > It seems to me that backporting 'secrets' and putting it on Warehouse would > be a lot more productive than complaining about 3.5.2 reverting to (almost) > the behavior of 2.3-3.4.
"Let Flask/Django/passlib/cryptography/whatever handle the problem rather than rolling your own" is already the higher level meta-guidance. However, there are multiple levels of improvement being pursued here, since developer ignorance of security concerns and problematic defaults at the language level is a chronic problem rather than an acute one (and one that affects all languages, not just Python). In that context, the main benefit of the secrets module is as a deterrent against people reaching for the reproducible simulation focused random module to implement security sensitive operations. By offering both secrets and random in the standard library, we help make it clear that secrecy and simulation are *not the same problem*, even though they both involve random numbers. Folks that learn Python 3.6 first and then later start supporting earlier versions are likely to be more aware of the difference, and hence go looking for "What's the equivalent of the secrets module on earlier Python versions?" (at which point they can just copy whichever one-liner they actually need into their particular application - just as not every 3 line function needs to be a builtin, not every 3 line function needs to be a module on PyPI) The os.urandom proposal is aimed more at removing any remaining equivocation from the longstanding "Use os.urandom() for security sensitive operations in Python" advice - it's for the benefit of folks that are *already* attempting to do the right thing given the tools they have available. The sole source of that equivocation is that in some cases, at least on Linux, and potentially on *BSD (although we haven't seen a confirmed reproducer there), os.urandom() may return results that are sufficiently predictable to be inappropriate for use in security sensitive applications. At the moment, determining whether or not you're risking exposure to that problem requires that you know a whole lot about Linux (and *BSD, where even we haven't been able to determine the level of exposure on embedded systems), and also about how ``os.urandom()`` is implemented on different platforms. My proposal is that we do away with the requirement for all that assumed knowledge and instead say "Are you using os.urandom(), random.SystemRandom(), or an API in the secrets module? Are you using Python 3.6+? Did it raise BlockingIOError? No? Then you're fine". The vast majority of Python developers will thus be free to remain entirely ignorant of these platform specific idiosyncracies, while those that have a potential need to know will get an exception from the interpreter that they can then feed into a search engine and get pointed in the right direction. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
