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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4