On 23 March 2014 08:53, Ben Darnell <b...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
