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

Antoine Pitrou solipsis at pitrou.net
Fri Nov 8 18:39:35 CET 2013

Le 08/11/2013 17:39, Christian Heimes a écrit :

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.

It's not an improvement, you are proposing to remove existing arguments to stdlib functions/constructors. I agree it would be cleaner without them, but there's no rush really.

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.

Whether "secure by default" happens in 3.4 or 3.5 doesn't change my point.

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.

Ok, fine with me, then.

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.

I don't really like it. There are already two steps: cert validation and cert matching, this idea is adding a third step and therefore making things extra confusing.

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!

Actually, sensible people will use a closure, but you can prefer thread-local storage or sys._getframe() if that's your taste in programming.

Regards

Antoine.

More information about the Python-Dev mailing list