<p dir="ltr"><br>
On 8 May 2015 9:52 pm, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
><br>
> Using an environment variable to disable a security feature sounds like<br>
> an extremely bad idea. Environment variables are hidden state.<br>
> Generally you don't know up front which values they will have when<br>
> running an executable, and people don't think about inspecting them.<br>
> This opens the door to mistakes (or even attacks) where certificate<br>
> validation is disabled without the user knowing.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Regards<br>
><br>
> Antoine.<br>
><br>
><br>
><br>
> On Fri, 08 May 2015 12:13:52 +0200<br>
> "M.-A. Lemburg" <<a href="mailto:mal@egenix.com">mal@egenix.com</a>> wrote:<br>
> > On 08.05.2015 11:36, Nick Coghlan wrote:<br>
> > > On 8 May 2015 6:52 pm, "M.-A. Lemburg" <<a href="mailto:mal@egenix.com">mal@egenix.com</a>> wrote:<br>
> > >><br>
> > >> On 07.05.2015 04:30, Nick Coghlan wrote:<br>
> > >>>> Can we please make the monkeypatch a regular part of Python's<br>
> > >>>> site.py which can enabled via an environment variable, say<br>
> > >>>> export PYTHONHTTPSVERIFY=0.<br>
> > >>>><br>
> > >>>> See <a href="http://bugs.python.org/issue23857">http://bugs.python.org/issue23857</a> for the discussion.<br>
> > >>> ...<br>
> > >>> I actually do think it would be good to have such a feature as a<br>
> > >>> native part of Python 2.7 in order to provide a nicer "revert to the<br>
> > >>> pre-PEP-476 behaviour" experience for Python 2.7 users (leaving the<br>
> > >>> "there's no easy way to turn HTTPS certificate verification off<br>
> > >>> globally" state of affairs to Python 3), but I don't currently have<br>
> > >>> the time available to push for that against the "end users can't be<br>
> > >>> trusted not to turn certificate verification off when they should be<br>
> > >>> fixing their certificate management instead" perspective.<br>
> > >><br>
> > >> We're currently working on a new release of eGenix PyRun and this<br>
> > >> will include Python 2.7.9.<br>
> > >><br>
> > >> We do want to add such an env switch to disable the cert verification,<br>
> > >> so would like to know whether we can use PYTHONHTTPSVERIFY for this<br>
> > >> or not.<br>
> > ><br>
> > > That's a slightly misleading quotation of my post, as I'm opposed to the<br>
> > > use of an environment variable for this, due to the fact that using the<br>
> > > "-E" switch will then revert to the upstream default behaviour of verifying<br>
> > > certificates, rather defeating the point of introducing the legacy<br>
> > > infrastructure compatibility feature in the first place.<br>
> ><br>
> > Oh, sorry. I read your email implying that you are fine with<br>
> > the env var approach.<br>
> ><br>
> > I don't really see the issue with -E, though. It's well possible<br>
> > to internally set PYTHONHTTPSVERIFY=0 when -E is used to regain<br>
> > backwards compatibility per default for Python 2.7.<br>
> ><br>
> > Regarding the config file approach and letting distributions<br>
> > set their own defaults:<br>
> ><br>
> > I don't think it's a good idea to have one distribution<br>
> > default to verifying HTTPS certs via a global config file<br>
> > and another distribution do the opposite.<br>
> ><br>
> > Python itself should define the defaults to be used, not<br>
> > the distributions.<br>
> ><br>
> > The Python Linux distribution is too complex already due to the<br>
> > many different ways Python is installed on the systems.<br>
> ><br>
> > Not having to deal with this complexity was the main motivation<br>
> > for us to create eGenix PyRun, since it works the same on<br>
> > all Linux platforms and doesn't use any of the system<br>
> > wide installed Python interpreters, settings or packages<br>
> > (unless you tell it to).<br>
> ><br>
> > > A new informational PEP akin to PEP 394 that defines a config file location<br>
> > > & contents for downstream redistributors that need a smoother transition<br>
> > > plan for PEP 476 will let us handle this in a consistent way across<br>
> > > redistributors that's also compatible with runtime use of the -E switch.<br>
> ><br>
> > Regardless of whether a global config file is a good idea or not,<br>
> > I don't think we can wait with 2.7.10 until a whole new PEP process<br>
> > has run through.<br>
> ><br>
> > > Cheers,<br>
> > > Nick.<br>
> > ><br>
> > >><br>
> > >> We mainly need this to reenable simple use of self-signed certificates<br>
> > >> which 2.7.9 disables.<br>
> > >><br>
> > >> --<br>
> > >> Marc-Andre Lemburg<br>
> > >> eGenix.com<br>
> > >><br>
> > >> Professional Python Services directly from the Source  (#1, May 08 2015)<br>
> > >>>>> Python Projects, Coaching and Consulting ...  <a href="http://www.egenix.com/">http://www.egenix.com/</a><br>
> > >>>>> mxODBC Plone/Zope Database Adapter ...       <a href="http://zope.egenix.com/">http://zope.egenix.com/</a><br>
> > >>>>> mxODBC, mxDateTime, mxTextTools ...        <a href="http://python.egenix.com/">http://python.egenix.com/</a><br>
> > >> ________________________________________________________________________<br>
> > >><br>
> > >> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::<br>
> > >><br>
> > >>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48<br>
> > >>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg<br>
> > >>            Registered at Amtsgericht Duesseldorf: HRB 46611<br>
> > >>                <a href="http://www.egenix.com/company/contact/">http://www.egenix.com/company/contact/</a><br>
> > ><br>
> ><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>