[Python-Dev] Backwards compatibility after certificate autovalidation
ncoghlan at gmail.com
Tue Sep 9 22:31:58 CEST 2014
On 10 Sep 2014 02:11, "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:
> >> I assume that adding _unverified_urlopen or urlopen(context=...) do
> >> provide incremental improvements compatible with the eventual full
> >> opt-in. If so, adding them is probably reasonable, but I think the
> >> PEP should explicitly list all such approved half-measures as a guard
> >> against API feature creep.
> > 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?
I'd still like to do that for 3.5+ as the proper long term fix, but I don't
think it's necessary for 2.7 or 3.4.
> For reference:
> I came up with the idea to introduce the module "sslcustomize" similar
> to sitecustomize. Contrary to sitecustomize the module is imported at
> the end of the ssl module.
> Based on my idea Nick proposed another addition to the SSL module. He
> proposed a ssl.named_contexts mapping from module names to factory
> functions that create SSLContext objects.
> I still prefer the general idea over the monkey patching idea because it
> provides a clean but simple interface for structured configuration.
> Monkey patching of stdlib modules is ugly and error-prone.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev