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

[Ben Darnell]

On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan <ncoghlan at 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/deadsnakesonly 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 at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140322/48f042bb/attachment-0001.html>