[Python-Dev] Backwards compatibility after certificate autovalidation
ncoghlan at gmail.com
Tue Sep 9 05:03:53 CEST 2014
On 9 Sep 2014 10:48, "Jim J. Jewett" <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
2. a documented way to restore the old behaviour via sitecustomize (which
may involve monkeypatching)
The former change seems non-controversial.
I think the more fine-grained solution for the latter can wait until 3.5
(and will be an independent PEP), we just need an interim workaround for
3.4 that could conceivably be backported to 2.7.
On that front, ssl currently has two context factories:
get_default_context() and _get_stdlib_context. One possible option would be
1. Rename "_get_stdlib_context" to "_get_unverified_context"
2. Add "_get_https_context" as an alias for "get_default_context"
Opting out on a per-call basis means passing an unverified context.
Opting out globally would mean monkeypatching _get_https_context to refer
to _get_unverified_context instead.
These would both be documented as part of transition, but with clear
security warnings. The use of the leading underscores in the names is
intended to emphasise "you probably don't want to be using this".
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev