[Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements (original) (raw)

Stephen J. Turnbull turnbull at sk.tsukuba.ac.jp
Tue Mar 25 19:53:30 CET 2014

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

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 | ncoghlan at gmail.com | Brisbane, Australia

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stephen%40xemacs.org

More information about the Python-Dev mailing list