Re: [Python-Dev] PYTHONHTTPSVERIFY env var (was: Clarification of PEP 476 "opting out" section)
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. 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/archive%40mail-archive.com
Re: [Python-Dev] PYTHONHTTPSVERIFY env var (was: Clarification of PEP 476 "opting out" section)
On 8 May 2015 6:52 pm, "M.-A. Lemburg" 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. 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. 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/archive%40mail-archive.com
Re: [Python-Dev] PYTHONHTTPSVERIFY env var
On 08.05.2015 11:36, Nick Coghlan wrote: > On 8 May 2015 6:52 pm, "M.-A. Lemburg" 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/ > -- 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/archive%40mail-archive.com
Re: [Python-Dev] PYTHONHTTPSVERIFY env var
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. Regards Antoine. On Fri, 08 May 2015 12:13:52 +0200 "M.-A. Lemburg" wrote: > On 08.05.2015 11:36, Nick Coghlan wrote: > > On 8 May 2015 6:52 pm, "M.-A. Lemburg" 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/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-05-01 - 2015-05-08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4838 ( -3) closed 31069 (+44) total 35907 (+41) Open issues with patches: 2252 Issues opened (25) == #24107: Add support for retrieving the certificate chain http://bugs.python.org/issue24107 opened by Lukasa #24109: Documentation for difflib uses optparse http://bugs.python.org/issue24109 opened by idahogray #24110: zipfile.ZipFile.write() does not accept bytes arcname http://bugs.python.org/issue24110 opened by july #24111: Valgrind suppression file should be updated http://bugs.python.org/issue24111 opened by Antony.Lee #24114: ctypes.utils uninitialized variable 'path' http://bugs.python.org/issue24114 opened by kees #24115: PyObject_IsInstance() and PyObject_IsSubclass() can fail http://bugs.python.org/issue24115 opened by serhiy.storchaka #24116: --with-pydebug has no effect when the final python binary is c http://bugs.python.org/issue24116 opened by aleb #24117: Wrong range checking in GB18030 decoder. http://bugs.python.org/issue24117 opened by Ma Lin #24119: Carry comments with the AST http://bugs.python.org/issue24119 opened by brett.cannon #24120: pathlib.(r)glob stops on PermissionDenied exception http://bugs.python.org/issue24120 opened by Gregorio #24124: Two versions of instructions for installing Python modules http://bugs.python.org/issue24124 opened by skip.montanaro #24126: newlines attribute does not get set after calling readline() http://bugs.python.org/issue24126 opened by arekfu #24127: Fatal error in launcher: Job information querying failed http://bugs.python.org/issue24127 opened by gavstar #24129: Incorrect (misleading) statement in the execution model docume http://bugs.python.org/issue24129 opened by levkivskyi #24130: Remove -fno-common compile option from OS X framework builds? http://bugs.python.org/issue24130 opened by ned.deily #24131: [configparser] Add section/option delimiter to ExtendedInterpo http://bugs.python.org/issue24131 opened by giflw #24132: Direct sub-classing of pathlib.Path http://bugs.python.org/issue24132 opened by projetmbc #24136: document PEP 448 http://bugs.python.org/issue24136 opened by benjamin.peterson #24137: Force not using _default_root in IDLE http://bugs.python.org/issue24137 opened by serhiy.storchaka #24138: Speed up range() by caching and modifying long objects http://bugs.python.org/issue24138 opened by larry #24139: Use sqlite3 extended error codes http://bugs.python.org/issue24139 opened by Dima.Tisnek #24140: In pdb using "until X" doesn't seem to have effect in commands http://bugs.python.org/issue24140 opened by vyktor #24142: ConfigParser._read doesn't join multi-line values collected wh http://bugs.python.org/issue24142 opened by fhoech #24143: Makefile in tarball don't provide make uninstall target http://bugs.python.org/issue24143 opened by krichter #24145: Support |= for parameters in converters http://bugs.python.org/issue24145 opened by larry Most recent 15 issues with no replies (15) == #24143: Makefile in tarball don't provide make uninstall target http://bugs.python.org/issue24143 #24140: In pdb using "until X" doesn't seem to have effect in commands http://bugs.python.org/issue24140 #24137: Force not using _default_root in IDLE http://bugs.python.org/issue24137 #24136: document PEP 448 http://bugs.python.org/issue24136 #24131: [configparser] Add section/option delimiter to ExtendedInterpo http://bugs.python.org/issue24131 #24129: Incorrect (misleading) statement in the execution model docume http://bugs.python.org/issue24129 #24115: PyObject_IsInstance() and PyObject_IsSubclass() can fail http://bugs.python.org/issue24115 #24114: ctypes.utils uninitialized variable 'path' http://bugs.python.org/issue24114 #24111: Valgrind suppression file should be updated http://bugs.python.org/issue24111 #24104: Use after free in xmlparser_setevents (2) http://bugs.python.org/issue24104 #24103: Use after free in xmlparser_setevents (1) http://bugs.python.org/issue24103 #24097: Use after free in PyObject_GetState http://bugs.python.org/issue24097 #24087: Documentation doesn't explain the term "coroutine" (PEP 342) http://bugs.python.org/issue24087 #24084: pstats: sub-millisecond display http://bugs.python.org/issue24084 #24063: Support Mageia and Arch Linux in the platform module http://bugs.python.org/issue24063 Most recent 15 issues waiting for review (15) = #24145: Support |= for parameters in converters http://bugs.python.org/issue24145 #24142: ConfigParser._read doesn't join multi-line values collected wh http://bugs.python.org/issue24142 #24138: Speed up range() by caching and modifying long objects http://bugs.python.org/iss
[Python-Dev] coming soon: 2.7.10
In the spirit of regular releases, it's time to release 2.7.10. I'm going to plan to cut rc1 this weekend with a final in 2 weeks. I apologize for the short notice; time has crept up on me, and I have commitments in June that prevent pushing releases into that month. ___ 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
Re: [Python-Dev] PYTHONHTTPSVERIFY env var
On 8 May 2015 9:52 pm, "Antoine Pitrou" 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" wrote: > > On 08.05.2015 11:36, Nick Coghlan wrote: > > > On 8 May 2015 6:52 pm, "M.-A. Lemburg" 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 > > >>
Re: [Python-Dev] PYTHONHTTPSVERIFY env var
On 8 May 2015 8:14 pm, "M.-A. Lemburg" wrote: > > On 08.05.2015 11:36, Nick Coghlan wrote: > > On 8 May 2015 6:52 pm, "M.-A. Lemburg" 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, Ski
