[Python-Dev] Clarification of PEP 476 "opting out" section

Nick Coghlan ncoghlan at gmail.com
Thu May 7 04:30:40 CEST 2015

On 30 Apr 2015 5:59 pm, "M.-A. Lemburg" <mal at egenix.com> wrote:

> On 30.04.2015 02:33, Nick Coghlan wrote:
> > Hi folks,
> >
> > This is just a note to highlight the fact that I tweaked the "Opting
> > out" section in PEP 476 based on various discussions I've had over the
> > past few months: https://hg.python.org/peps/rev/dfd96ee9d6a8
> >
> > The notable changes:
> >
> > * the example monkeypatching code handles AttributeError when looking
> > up "ssl._create_unverified_context", in order to accommodate older
> > versions of Python that don't have PEP 476 implemented
> > * new paragraph making it clearer that while the intended use case for
> > the monkeypatching trick is as a workaround to handle environments
> > where you *know* HTTPS certificate verification won't work properly
> > (including explicit references to sitecustomize.py and Standard
> > Operating Environments for Python), there's also a secondary use case
> > in allowing applications to provide a system administrator controlled
> > setting to globally disable certificate verification (hence the change
> > to the example code)
> > * new paragraph making it explicit that even though we've improved
> > Python's default behaviour, particularly security sensitive
> > applications should still provide their own context rather than
> > relying on the defaults
> Can we please make the monkeypatch a regular part of Python's
> site.py which can enabled via an environment variable, say
> See http://bugs.python.org/issue23857 for the discussion.
> Esp. for Python 2.7.9 the default verification from PEP 476
> is causing problems for admins who want to upgrade their
> Python installation without breaking applications using
> Python. They need an easy and official non-hackish way to
> opt-out from the PEP 476 default on a per application basis.

My current recommendation to the Red Hat Python team is to put
together a draft PEP 394 style informational PEP to define a
documented configuration file based approach that redistributors may
choose to implement in order to provide a smoother transition path for
their end users:

The problem I identified with reusing the environment variable based
approach that we used with hash randomisation is that "-E" turns the
upstream default behaviour back on. That was acceptable for hash
randomisation, but would be too limiting here (as the appropriate
value for the HTTPS certificate verification configuration setting
relates primarily to the general state of SSL/TLS certificate
management in the environment where Python is being deployed, moreso
than to the specific networked applications that are being run).

I actually do think it would be good to have such a feature as a
native part of Python 2.7 in order to provide a nicer "revert to the
pre-PEP-476 behaviour" experience for Python 2.7 users (leaving the
"there's no easy way to turn HTTPS certificate verification off
globally" state of affairs to Python 3), but I don't currently have
the time available to push for that against the "end users can't be
trusted not to turn certificate verification off when they should be
fixing their certificate management instead" perspective.


More information about the Python-Dev mailing list