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.
_______________________________________________
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
