Also important to remember that pip itself uses the OpenSSL binding in the ssl module so there is a chicken and egg problem.
> On Mar 22, 2014, at 7:49 PM, Donald Stufft <don...@stufft.io> wrote: > > In the case of requests they already have an optional dependency on > pyopenssl. It's just many people either don't know they should use it, are > unable to use it, or unwilling to use the python packaging tool chain because > of its current flaws. > >> On Mar 22, 2014, at 7:42 PM, Ben Darnell <b...@bendarnell.com> wrote: >> >>> On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan <ncogh...@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 | 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/donald%40stufft.io > _______________________________________________ > 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/donald%40stufft.io
_______________________________________________ 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
