Le 07/11/2013 22:42, Christian Heimes a écrit : > Am 07.11.2013 21:45, schrieb Antoine Pitrou: >> I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is >> quite young. > > It's available since 3.3 3.2 actually, while many code bases are still 2.x-compatible. There's no need to make migration more annoying right now. >>> - deprecate implicit verify_mode=CERT_NONE. Python 3.5 will default >>> to CERT_REQUIRED. >> >> -0.9. This breaks compatibility and doesn't achieve anything, since >> there's no reliable story for CA certs. > > I'd like to move to "secure by default". The CA cert situation is solved > on most platforms. 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). >>> - add ssl.get_default_context() to acquire a default SSLContext object >>> if the context argument is None. (Python 3.4) >> >> I think I'm against it, for two reasons: >> >> 1. It will in the long term create compatibility and/or security issues >> (we'll have to keep fragile legacy settings if we want to avoid breaking >> existing uses of the default context) >> >> 2. SSLContexts are mutable, which means some code can affect other >> code's behaviour without even knowing. It's a recipe for subtle bugs and >> security issues. >> >> Applications and/or higher-level libraries should be smart enough to >> choose their own security preferences, and it's the better place to do >> so anyway. > > You misunderstood me. I'm not proposing a global SSLContext object but a > factory function that creates a context for Python stdlib modules. Right > now every urllib, http.client, nntplib, asyncio, ftplib, poplib and > imaplib have duplicated code. I'd like to have ONE function that creates > and configures a SSLContext object with sensible default values for > Python stdlib. 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. >> I'm against calling it check_cert(), it's too generic and only induces >> confusion. > > Do you have an idea for a better name? match_service()? match_cert()? 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). >> And why is there an "initiator" object? Personally I prefer to avoid >> passing opaque user data, since the caller can use a closure anyway. >> And what are the **kwargs? > > No, they can't use a closure. The callback function is part of the > SSLContext object. > The context object can be used by multiple SSLSocket > objects. So what? If you want to use multiple callbacks or closures, you can create multiple context objects. > 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. >> So what does this bring compared to the statu quo? I thought at least >> sock.check_cert() would be called automatically, but if you have to call >> it yourself it starts looking pointless, IMO. > > As you have said earlier, cert matching is not strictly a SSL connection > thing. With the check_cert feature you can do stuff like validation of > self-signed certs with known hash sums: Ok, so you can pass that context to e.g. httplib, right? I'm convinced, except on the "user data" part :) 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