[Python-Dev] PYTHONHTTPSVERIFY env var

Sat May 9 01:56:25 CEST 2015

On 8 May 2015 9:52 pm, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
>
>
> Using an environment variable to disable a security feature sounds like
> an extremely bad idea. Environment variables are hidden state.
> Generally you don't know up front which values they will have when
> running an executable, and people don't think about inspecting them.
> This opens the door to mistakes (or even attacks) where certificate
> validation is disabled without the user knowing.

Yes, that's also a consideration. A config file lets us bring the full
battery of Linux security tools (most obviously file system permissions,
but also other systems like SELinux & AppArmor) to bear on controlling who
(and what) has permission to change the default security settings.

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
>
> On Fri, 08 May 2015 12:13:52 +0200
> "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.
> >
> > 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/
> > >
> >
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150509/90063441/attachment.html>