[Python-Dev] PYTHONHTTPSVERIFY env var

Sat May 9 02:29:43 CEST 2015

On 8 May 2015 8:14 pm, "M.-A. Lemburg" <mal at egenix.com> wrote:
>
> On 08.05.2015 11:36, Nick Coghlan wrote:
> > On 8 May 2015 6:52 pm, "M.-A. Lemburg" <mal at egenix.com> wrote:
> >>
> >> On 07.05.2015 04:30, Nick Coghlan wrote:
> >>>> Can we please make the monkeypatch a regular part of Python's
> >>>> site.py which can enabled via an environment variable, say
> >>>> export PYTHONHTTPSVERIFY=0.
> >>>>
> >>>> See http://bugs.python.org/issue23857 for the discussion.
> >>> ...
> >>> 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.
> >>
> >> We're currently working on a new release of eGenix PyRun and this
> >> will include Python 2.7.9.
> >>
> >> We do want to add such an env switch to disable the cert verification,
> >> so would like to know whether we can use PYTHONHTTPSVERIFY for this
> >> or not.
> >
> > That's a slightly misleading quotation of my post, as I'm opposed to the
> > use of an environment variable for this, due to the fact that using the
> > "-E" switch will then revert to the upstream default behaviour of
verifying
> > certificates, rather defeating the point of introducing the legacy
> > infrastructure compatibility feature in the first place.
>
> Oh, sorry. I read your email implying that you are fine with
> the env var approach.
>
> I don't really see the issue with -E, though. It's well possible
> to internally set PYTHONHTTPSVERIFY=0 when -E is used to regain
> backwards compatibility per default for Python 2.7.
>
> Regarding the config file approach and letting distributions
> set their own defaults:
>
> I don't think it's a good idea to have one distribution
> default to verifying HTTPS certs via a global config file
> and another distribution do the opposite.
>
> Python itself should define the defaults to be used, not
> the distributions.

As a result of the discussions around both PEP 466 and 476, I'm now firmly
of the view that it's correct for the upstream Python community to assume
the public internet as its standard operating environment when it comes to
network security settings, and for those of us working for commercial
redistributors to subsequently bear the cost of adapting from that upstream
assumption to the different assumptions that may apply in the context of
organisational intranets.

That's also why I've come around to the view that an informational PEP with
recommendations for redistributors, rather than an actual change to Python
2.7, is the right answer (at least initially) when it comes to providing a
smoother transition plan for PEP 476 - the folks saying "it's a bad idea to
make this easy to turn off" are *right* from the perspective of operating
over the public internet, or with well designed internal SSL/TLS
certificate management, it's just also a *necessary* idea (in my view) to
help CIOs and other infrastructure leads responsibly and effectively manage
the wide range of risks associated with internal infrastructure upgrades.

Regards,
Nick.

>
> The Python Linux distribution is too complex already due to the
> many different ways Python is installed on the systems.
>
> Not having to deal with this complexity was the main motivation
> for us to create eGenix PyRun, since it works the same on
> all Linux platforms and doesn't use any of the system
> wide installed Python interpreters, settings or packages
> (unless you tell it to).
>
> > A new informational PEP akin to PEP 394 that defines a config file
location
> > & contents for downstream redistributors that need a smoother transition
> > plan for PEP 476 will let us handle this in a consistent way across
> > redistributors that's also compatible with runtime use of the -E switch.
>
> Regardless of whether a global config file is a good idea or not,
> I don't think we can wait with 2.7.10 until a whole new PEP process
> has run through.
>
> > Cheers,
> > Nick.
> >
> >>
> >> We mainly need this to reenable simple use of self-signed certificates
> >> which 2.7.9 disables.
> >>
> >> --
> >> Marc-Andre Lemburg
> >> eGenix.com
> >>
> >> Professional Python Services directly from the Source  (#1, May 08
2015)
> >>>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
> >>>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> >>
________________________________________________________________________
> >>
> >> ::::: Try our mxODBC.Connect Python Database Interface for free !
::::::
> >>
> >>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> >>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> >>            Registered at Amtsgericht Duesseldorf: HRB 46611
> >>                http://www.egenix.com/company/contact/
> >
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, May 08 2015)
> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
>
> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150509/0b34c33c/attachment-0001.html>