Nick Coghlan writes: > Changes to these modules will still need to undergo normal backwards > compatibility assessments to ensure their default behaviour remains > consistent with earlier Python 2.7 releases,
I find this wording confusing. Does this mean that (possibly imaginary example) where Python 3.n enables a new "host match" check by default that Python 2.7 doesn't have, Python 2.7 gets the ability to check "host match", but it defaults to off? > While this PEP does not make any changes to the core development team's > handling of security-fix-only branches that are no longer in active > maintenance, I wonder if it would be possible to generalize the approach to 2.7 in such a way that our repos can collect backports of security *enhancements* which we have reviewed, even though they wouldn't be distributed in a release? That way the distros can share their patches to 2.x, x < 7. > infrastructure on their platform. Accordingly, and independently of this > PEP, the Mac OS X binary installers were already going to be switched to > statically linker newer versions of OpenSSL [4]_ Typo: statically linker -> statically-linked > For better or for worse (mostly worse), there are some environments where Is that "For better or for worse (mostly worse)" really necessary? Consenting adults and all that. > the risk of latent security defects is more tolerated than even a slightly > increased risk of regressions in maintenance releases. This policy largely > excludes these environments from consideration where the modules covered by > the exemption are concerned Again, I think you can put a period here. The people making such decisions know what they're doing, at least they think they do. Just tell them they're on they're own now, and their complaints, if any, will fall on deaf ears. > Downstream redistributors may still choose to cater to such environments, > but they will need to handle the process of downgrading the security > related modules and doing the associated regression testing themselves. > The main CPython continuous integration infrastructure will not cover this > scenario. This is how to write it, I think. > Motivation and Rationale > ======================== > > This PEP can be seen as a more targeted version of the "faster standard > library release cycle" proposals discussed in PEP 407 and PEP 413, > focusing specifically on those areas which have implications beyond the > Python community. FWIW, I don't see it that way at all. > It is worth comparing the approach described in this PEP with Red Hat's > handling of its long term support commitments: it isn't the RHEL 6.0 release > itself that receives 10 years worth of support, but the overall RHEL 6 > *series*. The individual RHEL 6.x point releases within the series then > receive a wide variety of new features, including security enhancements, > all while meeting strict backwards compatibility guarantees for existing > software. I don't understand this comparison. I think it requires too much familiarity with Red Hat policy to be useful to the great majority of readers, ie, it tells them a lot more about Red Hat then it does about Python. > However, now that we're fully aware of the impact the limitations of the > Python 2 standard library may be having on the evolution of internet > security standards, I suggest s/evolution/implementation/ here. > As Terry Reedy noted, URL? > Alternative: create and release Python 2.8 > ------------------------------------------ I don't see how this can possibly be viable. It would have to involve essentially the same restrictions as this PEP, or it completely fails to satisfy the requirements of downstreams. Even then, it would be a huge, uphill PR battle for downstreams trying to enhance their current 2.7 with the content of this PEP. > > With sufficient corporate support, it likely *would* be possible to create > and release Python 2.8 (it's highly unlikely such a project would garner > enough interest to be achievable with only volunteers). However, this > wouldn't actually solve the problem, as the aim is to provide a *relatively > low impact* way to incorporate enhanced security features into integrated > products and deployments that make use of Python 2. > > Upgrading to a new Python feature release would mean both more work for the > core development team, as well as a more disruptive update that most > potential end users would likely just skip entirely. > > Attempting to create a Python 2.8 release would also bring in suggestions > to backport many additional features from Python 3 (such as ``tracemalloc`` > and the improved coroutine support), making the migration from Python 2.7 > to this hypothetical 2.8 release even riskier and more disruptive. > > This is not a recommended approach, as it would involve substantial > additional work for a result that is actually less effective in achieving > the original aim (which is to eliminate the current widespread use of the > aging network security infrastructure in the Python 2 series). > > Furthermore, while I can't make any commitments to actually addressing > this issue on Red Hat platforms, I *can* categorically rule out the idea > of a Python 2.8 being of any use to me in even attempting to get it > addressed. > > > Alternative: distribute the security enhancements via PyPI > ---------------------------------------------------------- > > While this initially appears to be an attractive and easier to manage > approach, it actually suffers from several significant problems. > > Firstly, this is complex, low level, cross-platform code that integrates > with the underlying operating system across a variety of POSIX platforms > (including Mac OS X) and Windows. The CPython BuildBot fleet is already set > up to handle continuous integration in that context, but most of the > freely available continuous integration services just offer Linux, and > perhaps paid access to Windows. Those services work reasonably well for > software that largely runs on the abstraction layers offered by Python and > other dynamic languages, as well as the more comprehensive abstraction > offered by the JVM, but won't suffice for the kind of code involved here. > > The OpenSSL dependency for the network security support also qualifies as > the kind of "complex binary dependency" that isn't yet handled well by the > ``pip`` based software distribution ecosystem. Relying on a third party > binary dependency also creates potential compatibility problems for ``pip`` > when running on other interpreters like ``PyPy``. > > Another practical problem with the idea is the fact that ``pip`` itself > relies on the ``ssl`` support in the standard library (with some additional > support from a bundled copy of ``requests``, which in turn bundles > ``backport.ssl_match_hostname``), and hence would require any replacement > module to also be bundled within ``pip``. This wouldn't pose any > insurmountable difficulties (it's just another dependency to vendor), but > it *would* mean yet another copy of OpenSSL to keep up to date. > > This approach also has the same flaw as all other "improve security by > renaming things" approaches: they completely miss the users who most need > help, and raise significant barriers against being able to encourage users > to do the right thing when their infrastructure supports it (since > "use this other module" is a much higher impact change than "turn on this > higher security setting"). Deprecating the aging SSL infrastructure in the > standard library in favour of an external module would be even more user > hostile than accepting the slightly increased risk of regressions associated > with upgrading it in place. > > Last, but certainly not least, this approach suffers from the same problem > as the idea of doing a Python 2.8 release: likely not solving the actual > problem. Commercial redistributors of Python are set up to redistribute > *Python*, and a pre-existing set of additional packages. Getting new > packages added to the pre-existing set *can* be done, but means approaching > each and every redistributor and asking them to update their > repackaging process accordingly. By contrast, the approach described in > this PEP would require redistributors to deliberately *opt out* of the > security enhancements by deliberately downgrading the provided network > security infrastructure, which most of them are unlikely to do. > > > Alternative: provide a "legacy SSL infrastructure" branch > --------------------------------------------------------- > > Earlier versions of this PEP included the concept of a ``2.7-legacy-ssl`` > branch that preserved the exact feature set of the Python 2.7.6 network > security infrastructure. > > It is the opinion of the PEP author that anyone that actually wants this is > almost certainly making a mistake, and if they insist they really do want > it in their specific situation, they're welcome to either make it themselves > or arrange for a downstream redistributor to make it for them. > > If they are made publicly available, any such rebuilds should be referred to > as "Python 2.7 with Legacy SSL" to clearly distinguish them from the official > Python 2.7 releases that include more up to date network security > infrastructure. > > After the first Python 2.7 maintenance release that has the security > infrastructure updated to match Python 3.4, it would also be appropriate to > refer to Python 2.7.6 and earlier releases as "Python 2.7 with Legacy SSL". > > > Alternative: selectively backport particular APIs > ------------------------------------------------- > > An instinctively minimalist reaction to this proposal is to only backport > particular APIs in the affected modules that are judged to be "security > critical". However, this ends up providing a worse end user experience, > as well as a worse developer experience. > > For end users, the selective backporting approach means learning not only > the legacy Python 2.7 API and the current Python 3 APIs, but also the > hybrid API created by the selective backporting process. It is much > simpler to just learn the APIs of the original Python 2.7 feature release > and the relevant Python 3 features releases, without trying to define a new > hybrid API that only exists in later Python 2.7 maintenance branches. > > For developers, the main benefit of the "just align the available > functionality with Python 3" approach is that it reduces the amount of > design work needing when updating Python 2.7 with new security features. > The "feature or fix?" and "security related or not?" debates are both > handled in advance by this policy, leaving only the matter of ensuring > that backwards compatibility is preserved as needed by adjusting the > default behaviour in the Python 2.7 backport when appropriate. > > > Open Questions > ============== > > * MvL has indicated he is not prepared to tackle the task of trying to > integrate a newer OpenSSL into the also aging Python 2.7 build > infrastructure on Windows (unfortunately, we've looked into upgrading > that build infrastructure, and the backwards compatibility issues > appear to be effectively insurmountable). We would require a commitment > from another trusted contributor to handle at least this task, and > potentially also taking over the task of creating the official > Python 2.7 Windows installers for the remaining Python 2.7 maintenance > releases. > > * We would need commitments to create and review full backports of the > components covered by this policy from Python 3.4 to Python 2.7, as well > as support for handling any more specific security issues affecting these > modules. > > * I believe I've addressed all the technical and scope questions I had, or > others raised. That just leaves the question of "Do we agree this plan > actually makes sense, given the constraints on downstream redistributors > that would also like to see this problem solved?" :) > > > Disclosure of Interest > ====================== > > The author of this PEP currently works for Red Hat on test automation tools. > If this proposal is accepted, I will be strongly encouraging Red Hat to take > advantage of the resulting opportunity to help improve the overall security > of the Python ecosystem. However, I do not speak for Red Hat in this matter, > and cannot make any commitments on Red Hat's behalf. > > > Acknowledgements > ================ > > Thanks to Christian Heimes for his recent efforts on greatly improving > Python's SSL support in the Python 3 series, and a variety of members of > the Python community for helping me to better understand the implications > of the default settings we provide in our SSL modules, and the impact that > tolerating the use of SSL infrastructure that was defined in 2010 > (Python 2.7) or even 2008 (Python 2.6) potentially has for the security > of the web as a whole. > > Christian and Donald Stufft also provided valuable feedback on a preliminary > draft of this proposal. > > Thanks also to participants in the python-dev mailing list threads [1,2,5]_ > > > References > ========== > > .. [1] https://mail.python.org/pipermail/python-dev/2014-March/133334.html > .. [2] https://mail.python.org/pipermail/python-dev/2014-March/133389.html > .. [3] https://mail.python.org/pipermail/python-dev/2014-March/133438.html > .. [4] https://mail.python.org/pipermail/python-dev/2014-March/133347.html > .. [5] https://mail.python.org/pipermail/python-dev/2014-March/133442.html > > > -- > 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/stephen%40xemacs.org _______________________________________________ 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
