[Python-Dev] Simplify and unify SSL verification (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Fri Nov 8 22:15:05 CET 2013

On 9 Nov 2013 02:41, "Christian Heimes" <christian at python.org> wrote:

Am 08.11.2013 08:42, schrieb Antoine Pitrou: > 3.2 actually, while many code bases are still 2.x-compatible. > There's no need to make migration more annoying right now. There is also no need to hinder and delay future improvements for the sake of 2.x compatibility. Python 2.7.0 has been released in July 2010. Python 3.5 will be released late 2015. 3rd parties can backport Python 3.x ssl module if they need the new feature in 2.x, too. Seriously, it's time to set Python 3 free. Python 2.7 shall no longer be a millstone around Python 3's neck.

As long as there is a backports.ssl module, support in tulip and in requests, it's likely fine in terms of supporting the common 2/3 subset.

However, since this change mostly can be published via PyPI, I also don't think it makes sense to rush the design of this in the next two weeks.

Heck, testing on PyPI first would even allow for fixing the misnomer - currently we're importing the ssl module to access Python's TLS support, which can't be helping the widespread misunderstanding of the fact they're not quite the same thing (even though TLS superseded SSL).

The "create_default_context" idea and ensuring affected APIs accept a context object doesn't need to wait, nor does deprecating the implied CERT_NONE verification mode.

It's just the parameter deprecations and the matching customisation API I think should be delayed, since those have broader implications that I don't believe we can give adequate consideration in two weeks when there's already plenty of other work we're still trying to finish up.

Cheers, Nick.

> If it's not solved on all platforms then you're introducing a nasty > discrepancy between platforms. > > That said, "secure by default" could be a property of the "default > context factory" (see below). I think you forget that incompatible changes won't happen until Python 3.5. Developer and users can still have the insecure, non verified mode but they have to configure it explictly.

> Ok, so what about the long term compatibility issues? > > I'd be ok if you changed the name as suggested by Nick and if it was > explicit that the security settings for this context can change between > releases, therefore working code can break due to upgraded security > standards. Absolutely! Applications shall create their own context if they require full control. createdefaultcontext() return a sensible context object that is subject to changes between releases. > But, really, it strikes me that adding this method to SSLSocket may make > things more confusing. The docs will have to be clear that certificate > validation and certificate matching are two different things (that > is, you can't pass CERTNONE and then expect calling matchcert() is > sufficient). I like Nick's idea with verifyhostname flag and a postverify callback. At first the callback is invoked. Then the hostname is verified if either verifyhostname is true or None with CERTOPTIONAL / CERTREQUIRED. Similar to exit() the callback can return a true value in order to skip hostname matching. >> The **kwargs make it possible to pass data from the caller of >> checkcert() to the callback function of the SSLContext instance. > > Well, I think such explicit "user data" needn't exist in Python. Sure, people can just use thread local storage or walk up the stack with sys.getframe(). That's going to work well for asyncio! :p Christian

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131109/f0e1222c/attachment.html>

More information about the Python-Dev mailing list