On 30.08.2014 12:40, Antoine Pitrou wrote: > On 2014年8月30日 12:19:11 +0200 > "M.-A. Lemburg" <[email protected]> wrote: >>> 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. > > Python links against OpenSSL as a shared library, not statically. It's > unlikely that setting a compile constant inside Python would affect > OpenSSL at all.
The change is to the OpenSSL API, not the OpenSSL lib. By setting the variable you enable a few special calls to the config loader functions in OpenSSL when calling the initializer it: https://www.openssl.org/docs/crypto/OPENSSL_config.html >>> 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. > > That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE > env vars (or, better, by specific settings *inside* the application). > > I'm against multiplying environment variables, as it makes it more > difficult to assess the actual security of a setting. The danger of an > ill-secure setting is much more severe than with hash randomization. You have a point there. So how about just a python run-time switch and no env var ? -- 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com