[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements (original) (raw)

Chris Angelico rosuav at gmail.com
Mon Mar 24 20:37:41 CET 2014

On Mon, Mar 24, 2014 at 8:28 PM, Cory Benfield <cory at lukasa.co.uk> wrote:

On 24 March 2014 08:44, Nick Coghlan <ncoghlan at gmail.com> wrote:

The position I am coming to is that the "enhanced security" release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do "Python 2.7 with legacy SSL" releases if they so choose. I'm happier forcing end users to rely on a redistributor to opt in to a lower security option than I am to knowingly publish too many additional releases with network security infrastructure that is (at best) rapidly approaching its use by date. I'm with you here Nick, the default should really be "Python 2.7 with working TLS", not "Python 2.7 with broken TLS" (my only-slightly tongue-in-cheek proposed names for the releases). My concern with having Chris' proposal of an opt-in SEPython release is about discovery. I suspect most people will never find out about the SEPython release, meaning that most people will remain on insecure Python 2.7 distributions. If that happens, requests is essentially required to continue to support our current TLS model for 2.7 for as long as we support 2.7, and this PEP would give us no benefit at all. We're obviously not the only stakeholder here, but it's worth noting.

The opting in could be done at the distro level. Red Hat could ship a thing called /usr/bin/python that runs SEPython, and that package could be identified and numbered in such a way that it's clearly a drop-in replacement for vanilla Python. If backward compatibility is done carefully (which, from everything I'm seeing here, is the way it's to be done), there should be absolutely no downside to using SEPython, except for portability (because now you're depending on it for security), and corner cases like testing.

Alternatively, it can be done as a separate package: install "python" to get Python, and install "python-security-patches" or "python-tls" to get the tweaks - once that's installed, /usr/bin/python becomes SEPython. Programs can depend on that package to ensure security. That does have a partial discoverability problem (possibly even worse, as you could test on a computer that has x, y, z installed, and then deploy on a brand new computer, and nothing there ever depended on SEPython, so you're vulnerable without knowing why), but that could be ameliorated by simply advising people to type "yum install python-tls" if they want to run any Python programs that use TLS. But I'd be inclined to the first option; its biggest downside is that installing "python" installs something other than the "standard stdlib", which IMO isn't a big problem if (a) it's 100% backward compatible, and (b) it's semi-official anyway.

ChrisA

More information about the Python-Dev mailing list