It’s create_default_context() -> https://docs.python.org/3.4/library/ssl.html#ssl.create_default_context
> On Sep 8, 2014, at 11:40 PM, Guido van Rossum <gu...@python.org> wrote: > > The multiple threads going on are confusing (or maybe GMail makes them more > confusing), but the architecture you are sketching here sounds good. I can't > find get_default_context() in the repo, but perhaps I need to refresh, or > perhaps you're talking about a design in a PEP. > > On Mon, Sep 8, 2014 at 8:03 PM, Nick Coghlan <ncogh...@gmail.com > <mailto:ncogh...@gmail.com>> wrote: > > On 9 Sep 2014 10:48, "Jim J. Jewett" <jimjjew...@gmail.com > <mailto:jimjjew...@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". > > Regards, > Nick. > > > > > > > -jJ > > _______________________________________________ > > Python-Dev mailing list > > Python-Dev@python.org <mailto:Python-Dev@python.org> > > https://mail.python.org/mailman/listinfo/python-dev > > <https://mail.python.org/mailman/listinfo/python-dev> > > Unsubscribe: > > https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > > <https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com> > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org <mailto:Python-Dev@python.org> > https://mail.python.org/mailman/listinfo/python-dev > <https://mail.python.org/mailman/listinfo/python-dev> > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > <https://mail.python.org/mailman/options/python-dev/guido%40python.org> > > > > > -- > --Guido van Rossum (python.org/~guido <http://python.org/~guido>) > _______________________________________________ > 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/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ 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/archive%40mail-archive.com
