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

[Chris Angelico]

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