On 16 June 2016 at 05:50, Paul Moore <p.f.mo...@gmail.com> wrote: > On 16 June 2016 at 12:34, Donald Stufft <don...@stufft.io> wrote: >> [1] I don’t think using os.urandom is incorrect to use for security sensitive >> applications and I think it’s a losing battle for Python to try and fight >> the rest of the world that urandom is not the right answer here. >> >> [2] python-dev tends to favor not breaking “working” code over securing >> existing >> APIs, even if “working” is silently doing the wrong thing in a security >> context. This is particularly frustrating when it comes to security >> because >> security is by it’s nature the act of taking code that would otherwise >> execute and making it error, ideally only in bad situations, but this >> “security’s purpose is to make things break” nature clashes with >> python-dev’s >> default of not breaking “working” code in a way that is personally >> draining >> to me. > > Should I take it from these two statements that you do not believe > that providing *new* APIs that provide better security compared to a > backward compatible but flawed existing implementation is a reasonable > approach? And specifically that you don't agree with the decision to > provide the new "secrets" module as the recommended interface for > getting secure random numbers from Python? > > One of the aspects of this debate that I'm unclear about is what role > the people arguing that os.urandom must change see for the new secrets > module.
The secrets module is great for new code that gets to ignore any version of Python older than 3.6 - it's the "solve this problem for the next generation of developers" answer. All of the complicated "this API is safe for that purpose, this API isn't" discussions get replaced by "do the obvious thing" (i.e. use random for simulations, secrets for security). The os.urandom() debate is about taking the current obvious (because that's what the entire security community is telling you to do) low level way to do it and categorically eliminating any and all caveats on its correctness. Not "it's correct if you use these new flags that are incompatible with older Python versions". Not "it's not correct anymore, use a different API". Just "it's correct, and the newer your Python runtime, the more correct it is". 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
