On 4 September 2014 22:39, Antoine Pitrou firstname.lastname@example.org wrote:
On Thu, 4 Sep 2014 13:11:38 +1000 Nick Coghlan email@example.com wrote:
That leaves Python 2.7, and I have to say I'm now persuaded that a backport (including any required httplib and urllib features) is the right way to go. One of the tasks I'd been dreading as a follow-on from PEP 466 was organising the code audit to make sure our existing Python 2 applications are properly configuring SSL. If we instead change Python 2.7.9 to validate certificates by default, then the need to do that audit *goes away*, replaced by the far more mundane tasking of doing integration testing on 2.7.9, which we'd have to do *anyway*.
What are "our existing Python 2 applications"? Is it a Red Hat-specific statement? What is the "code audit" you are talking about?
Yes, that's a Red Hat specific statement. In addition to OpenStack, many of our other products include Python components. We mostly rely on pycurl, pyopenssl, python-nss, etc for SSL/TLS for historical reasons (since ssl wasn't available in the Python standard library until RHEL 6), which was why these concerns got picked up via the OpenStack community rather than the Fedora community. However, being aware of the problem creates that element of doubt as to whether there are *other* cases where someone used the stdlib ssl module rather than one of the alternatives that verifies HTTPS by default.
I'd previously been looking at the question while wearing my upstream core developer & CPython redistributor hats. Glyph et al finally prompted me to look at it while wearing my "automated quality assurance toolchain architect for an application vendor" hat (i.e. my actual day job), and that's a *radically* different perspective when it comes to a language runtime that fails to verify HTTPS connections correctly by default.
That's the core reason I changed my mind: this conversation forced me to think through how I could ensure correct HTTPS handling in all our Python code, and the only workable solution I now see is to fix it at the standard library level. The alternative is to prepare for the likelihood of future CVEs in Python based tools based on failure to properly verify SSL certificates, as I don't see a practical way of automatically detecting "tried to use HTTPS without verifying the SSL certificate properly".