On 1 December 2013 21:40, Antoine Pitrou <solipsis at pitrou.net> wrote: > On Sun, 1 Dec 2013 21:33:06 +1000 > Nick Coghlan <ncoghlan at 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 | ncoghlan at gmail.com | Brisbane, Australia
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