[Python-Dev] Simplify and unify SSL verification

[Antoine Pitrou]

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. create_default_context() 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 CERT_NONE and then expect calling match_cert() is
>> sufficient).
>
> I like Nick's idea with verify_hostname 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
>>> check_cert() 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! </irony>

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.