On 10 September 2014 07:13, Jim J. Jewett firstname.lastname@example.org wrote:
On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes email@example.com wrote:
On 09.09.2014 05:03, Nick Coghlan wrote:
On 9 Sep 2014 10:48, "Jim J. Jewett" <firstname.lastname@example.org mailto:email@example.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):
- "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.