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