On 24 June 2016 at 07:01, Barry Warsaw <ba...@python.org> wrote: > On Jun 24, 2016, at 12:11 AM, Victor Stinner wrote: > >>Once we modified Python 3.6 to handle correctly "the bug" and we >>consider that the implementation is tested enough, I suggest to >>backport it to Python 2.7 as well. Moreover, I would also suggest to >>backport the change to Python 3.5, I would be sad if Python 2 is more >>secure than the latest Python 3 release :-) > > This is the fundamental point of disagreement, and I think it points again to > a deficiency in our process. Regardless of outcome of this specific case, I > think we should try to tighten up our definitions and codify our policy in an > informational PEP. > > What criteria do we use to classify an issue as a security bug requiring a > fix, with backports, overriding any backward compatibility breaks? > > I think we've been largely ad-hoc about this question.
PEP 466 aimed to answer it: https://www.python.org/dev/peps/pep-0466/#why-these-particular-changes The most significant sentence in that section is this one: "The key requirement for a feature to be considered for inclusion in this proposal was that it must have security implications beyond the specific application that is written in Python and the system that application is running on." Earlier drafts of the PEP did aim to define that as a standard policy, but Guido nixed that idea, instead requesting that every such security related backport proposal receive its own dedicated PEP. For PEP 466, the limitations of the Python 2.7 standard library were holding back the evolution of network security in general (e.g. by acting as a brake on the adoption of Server-Name-Indication and on servers forcing TLS-only secure connections). For PEP 476, the mismatch between how people assumed the standard library handled HTTPS connections and how it actually did handle them was causing real security vulnerabilities in networked applications. For the PEPs currently under consideration, I don't think the situation is as critical as that - we're talking about a rare situation specific to secret generation on Linux with poorly configured entropy sources, not the core handling of SSL/TLS and HTTPS used by a large proportion of networked applications. That means I believe "Folks that genuinely care about secure secret generation should upgrade to Python 3.6 and a Linux kernel with getrandom() support" is an entirely reasonable position for us to take in this case. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
