On 9 Sep 2014 10:48, "Jim J. Jewett" <jimjjewett@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)

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 to:

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".


> -jJ
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com