On 8 May 2015 9:52 pm, "Antoine Pitrou" <solip...@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" <m...@egenix.com> wrote: > > On 08.05.2015 11:36, Nick Coghlan wrote: > > > On 8 May 2015 6:52 pm, "M.-A. Lemburg" <m...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
_______________________________________________ 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
