[Python-Dev] Verification of SSL cert and hostname made easy

Nick Coghlan ncoghlan at gmail.com
Sun Dec 1 12:54:59 CET 2013


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


More information about the Python-Dev mailing list