Am 01.12.2013 12:33, schrieb Nick Coghlan:
Perhaps a cleaner option would be to make check_hostname read only, and add a secure-by-default method that allows all verification related settings to be adjusted at once:
def set_verify_mode(mode=ssl.CERT_REQUIRED, check_hostname=True): ...That way the consistency check would be directly on the method arguments, rather than involving the current context state. Any future settings that required a verified cert could then use a similar model.
I don't like to add yet another API element to SSLContext. I'd rather extend SSLContext.__init__ to take two additional parameters:
class SSLContext(_SSLContext): def __init__(self, protocol, verify_mode=ssl.CERT_NONE, check_hostname=False): self.protocol = protocol self.verify_mode = verify_mode self.check_hostname = check_hostname
I also like to point out (again) that the requirement is only a limitation of our API. OpenSSL is able to acquire and return the peer's certificate with any mode. In the past somebody decided to map 'no certificate' to None and 'no verification' to empty dict.
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:
You are right, I'm trying to aim for the simplest and smallest solution possible. I'm well aware that the order of API calls is a limitation and that it feels a bit awkward, too. In my opinion there is no way this API can be screwed up. :) Any limitation can be lifted for 3.5 but we can't make it more restrict in future versions.
And there is ssl.create_default_context(), too. It creates a context with all security-related bits flipped on.
Christian