[Python-Dev] Backwards compatibility after certificate autovalidation

[Nick Coghlan]

On 10 September 2014 07:13, Jim J. Jewett <jimjjewett at gmail.com> wrote:
> On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes <christian at python.org> wrote:
>> On 09.09.2014 05:03, Nick Coghlan wrote:
>>>
>>> On 9 Sep 2014 10:48, "Jim J. Jewett" <jimjjewett at gmail.com
>>> <mailto:jimjjewett at gmail.com>> wrote:
>>> From Guido's and your feedback, I think we may need two things to
>>> approve this for 3.4.2 (putting 2.7 aside for now):
>
>>> 1. "context" parameter support in urllib.request (to opt out on a
>>> per-call basis)
>>> 2. a documented way to restore the old behaviour via sitecustomize
>>> (which may involve monkeypatching)
>
>> What's with our plan to introduce sslcustomize? Is the idea for a
>> configuration module and named contexts off the table?
>
> In a perfect world, half-measures would not be needed, and so neither
> would sslcustomize.
>
> In the real world, half-measures are needed, but offering too many of
> them adds so much confusion that things can actually get worse in
> practice.
>
> In other words, sslcustomize could be great, but getting it wrong
> would be a step backwards -- so start it as a 3rd party module.  Since
> the biggest users are likely supported customers of downstream
> distributions, it makes sense to let them take the lead, though I'm
> sure they would appreciate a proof of concept.

I see the use case for sslcustomize as being different: it wouldn't be
about turning the stdlib SSL security settings *down*, it would be
about selectively turning them *up*.

As PEP 476 says, turning cert validation on for protocols like SMTP is
currently going to cause significantly more problems than turning it
on for HTTPS. The cleaner, more comprehensive sslcustomize model would
provide a way to opt-in on a virtualenv and installation wide basis to
those higher security settings. The fact it would also offer a
slightly cleaner alternative to the HTTPS downgrade monkeypatch would
be an incidental side effect.

The change would touch many more modules than the current proposal
though, which is why I now believe it's better tackled as a 3.5+ only
feature.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia