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

[Nick Coghlan]

On 23 March 2014 08:53, Ben Darnell <ben at bendarnell.com> wrote:
> I agree wholeheartedly with the sentiment behind this PEP, but I have
> concerns about the implementation.  If we introduce new APIs into the ssl
> module then we will see packages and applications that depend on Python
> 2.7.7+, just like with the introduction of bool in 2.2.1.  This will be a
> mess unless adoption of new Python minor versions is swift and consistent.
> The PEP says that new features should be testable with feature detection,
> but how far does that go?  The Python 3 NPN interface is a method of
> SSLContext, which didn't exist in 2.7.  Do we backport the entire SSLContext
> interface in a minor release, or introduce a new NPN interface that is not
> based on SSLContext just for older Pythons?

The whole thing. The problem at the moment is that too many
applications just silently run without proper security settings on
older Python release, as users don't completely want to drop support
for that version, but also decide it's too hard to enable the right
security settings properly. The idea here is to make it easy for them
to enable the settings if they're available, but still fall back to
their old behaviour if they're not. The "fail or fall back" decision
will depend on the library and its assessment of security
compatibility vs breadth of support for legacy versions.

The issue isn't really the ssl module itself - it's the other modules
that *depend* on the ssl module (like httplib, urllib, poplib, ftplib,
imaplib). You could technically try to monkeypatch or shadow the
stdlib ssl module from a third party library, but that's a *really*
dangerous approach to security (since it makes it hard to do proper
integration testing).

> In my experience most deployments of Python apps have better systems in
> place to deal with packages installed from PyPI than new versions of Python
> itself.  Therefore it might be better to follow the lead of the unittest2
> module and introduce a new ssl2 module that tracks the most recent version
> of Python's ssl module.
>
> My counter-proposal is:
> * Introduce a new module 'ssl2' which is essentially a backport of the
> current release's ssl module for all old versions of Python that anyone
> cares to support.

It's not just ssl2: you needs os2, random2, ftplib2, poplib2,
imaplib2, smtplib2. You also run headlong into the problem of a
complex external dependency on OpenSSL (which the Linux distro
repackagers currently handle for us).

This is what the """reimplementing substantial portions of the
standard library as third party modules to gain access to the newer
underlying network security protocols and mechanisms, and then
injecting those into the module namespace to override their standard
library counterparts.""" comment is about, but I guess I should expand
on that for the benefit of readers not as familiar with the relevant
implementation details.

> * Third-party applications and libraries targeting anything but the latest
> version of Python are advised to use ssl2 instead of ssl (this might also be
> a good opportunity to bless certifi or an equivalent).
> * Minor releases of Python are allowed to make any security-related change
> that does not change any public interfaces (e.g. linking against a new
> version of openssl, or disabling SSLv2)

New versions of OpenSSL are nowhere near as useful when their
constants aren't made available in the Python API.

> * New interfaces in security-related modules are allowed only if those new
> interfaces are used by other stdlib modules (since stdlib modules are the
> only place where ssl2 is off-limits).  For example, a backport of
> match_hostname could go in if httplib or urllib used it.  NPN/ALPN would not
> be allowed under this rule since there is no stdlib code that uses them;
> third-party SPDY or HTTP/2 code would have to use ssl2 to get this
> interface.
>
> In this world, libraries like requests or tornado that want to use advanced
> ssl features can simply declare a dependency on ssl2, instead of saying "we
> require Python 2.7.7+, 3.2.6+, etc".

There's a reason the developers of those libraries haven't already
done that: it's genuinely hard. It's not that I didn't think of this
approach, it's that I think it would actually be more difficult and
less effective than the approach currently in the PEP.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia