On 1 December 2013 21:40, Antoine Pitrou <solip...@pitrou.net> wrote: > On Sun, 1 Dec 2013 21:33:06 +1000 > Nick Coghlan <ncogh...@gmail.com> wrote: >> >> If we don't do that, then I think Christian's approach is a reasonable >> compromise given the late stage of the release cycle - it ensures the >> context can't get into the inconsistent verify_mode=CERT_NONE and >> check_hostname=True state, and leaves our options completely open for >> 3.5: > > I would prefer the check to be made when the the socket is created, > i.e. the wrap_socket() call.
That was my initial reaction, but then I realised it creates a situation where the exception is raised at a point that differs from the source of the error (the bug is in the way the context was configured, but the exception won't be thrown until you actually try to wrap a socket). So I now agree with Christian that it's better to prevent the creation of the internally inconsistent SSL context in the first place, rather than delaying the detection of the inconsistency until the context is actually used. I think a read-only attribute and a combined setter method is a better way to achieve that (since it avoids the quirky "order of setting attributes matters" behaviour), but I'm also OK with read/write properties that internally enforce of the state invariant. If we decide the invariant enforcement in 3.4 is too strict, we can change our minds and relax things in 3.5. By contrast, if we allow the invariant to be broken in 3.4, we're locked in by backwards compatibility concerns and can't change our minds in the future. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
