On 30.08.2014 04:44, Alex Gaynor wrote: > Thanks for the rapid feedback everyone! > > I want to summarize the action items and discussion points that have come up > so > far: > > To add to the PEP: > > * Emit a warning in 3.4.next for cases that would raise a Exception in 3.5 > * Clearly state that the existing OpenSSL environment variables will be > respected for setting the trust root
I'd also suggest to compile Python with OPENSSL_LOAD_CONF, since that causes OpenSSL to read the global openssl.cnf file for additional configuration. > Discussion points: > > * Disabling verification entirely externally to the program, through a CLI > flag > or environment variable. I'm pretty down on this idea, the problem you hit > is > that it's a pretty blunt instrument to swing, and it's almost impossible to > imagine it not hitting things it shouldn't; it's far too likely to be used > in > applications that make two sets of outbound connections: 1) to some internal > service which you want to disable verification on, and 2) some external > service which needs strong validation. A global flag causes the latter to > fail silently when subjected to a MITM attack, and that's exactly what we're > trying to avoid. It also makes things much harder for library authors: I > write an API client for some API, and make TLS connections to it. I want > those to be verified by default. I can't even rely on the httplib defaults, > because someone might disable them from the outside. The reasoning here is the same as for hash randomization. There are cases where you want to test your application using self-signed certificates which don't validate against the system CA root list. In those cases, you do know what you're doing. The test would fail otherwise and the reason is not a bug in your code, it's just the fact that the environment you're running it in is a test environment. Ideally, all applications should give you this choice, but this is unlikely to happen, so it's good to be able to change the Python default, since with the proposed change, most applications will probably continue to use the Python defaults as they do now. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 30 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-08-27: Released eGenix PyRun 2.0.1 ... http://egenix.com/go62 2014-09-19: PyCon UK 2014, Coventry, UK ... 20 days to go 2014-09-27: PyDDF Sprint 2014 ... 28 days to go 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
