On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

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).

I suppose the difference is that the applications I've worked with have *already* abandoned stdlib modules like httplib or urllib in favor of libraries like requests and tornado, so I see this as mainly a question of whether the stdlib provides a suitable foundation for those packages.

The argument about the difficulty of integration testing cuts both ways - I can use tox to test Tornado with several versions of a third-party package, but cannot (as long as https://launchpad.net/~fkrull/+archive/deadsnakes only provides one package per x.y release) easily test with both Python 2.7.6 and 2.7.7.

> 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).

Just os2 and random2; as I said a few bullet points down the stdlib libraries that use ssl would be sufficient justification for additions to the ssl module's interface.

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.

In my proposal there is no monkey-patching; the newer ssl interfaces would come solely from the ssl2 module.

> * 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.

One of the reasons it's genuinely hard is that no one has provided an interface compatible with the stdlib ssl module. An ssl2 module that backported Python 3.4's ssl module would be a *much* more attractive porting target than e.g. PyOpenSSL.

-Ben

Cheers,
Nick.

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