On 24 November 2015 at 12:05, Barry Warsaw email@example.com wrote:
On Nov 17, 2015, at 11:44 PM, Nick Coghlan wrote:
For Debian, Ubuntu and SUSE, their original determinations for the relevant CVE were "too intrusive to backport", so folks currently need to upgrade to newer versions of those distros to get the improved default behaviour:
This is an example of my problem with the tone of PEP 493 (sorry Nick, nothing personal!). "Improved default behavior"... for whom? It's not improved for the folks whose applications are broken by changing the default.
I think there are three relevant categories here:
1. Folks who assume that "https" means the same thing in Python that it means in web browsers, and are currently experiencing a silent security failure 2. Folks who already know it doesn't, and are relying on that to keep their infrastructure working 3. Folks currently in group 2 who would like to improve their infrastructure to default to verifying certificates
The upstream change in PEP 476 was driven by the interests of folks in group 1. This makes a lot of sense, given that a popular way of introducing folks to programming now is by writing programs that interact with web APIs over HTTPS. Rebasing is fine for reaching desktop audiences, so this group should already have been covered by the updated python.org binaries for Windows and Mac OS X, new binary releases from the cross-platform redistributors, and updates to non-LTS Linux distros.
For folks in group 2, the main goal is "Don't break their stuff as a side effect of updating a supported version", which is why PEP 493 recommends leaving certificate verification disabled by default if backporting the PEP 476 changes.
The target audience for PEP 493 is then the folks in group 3: infrastructure operators that *want* to turn failures to validate certificates in Python applications into a noisy failure, but *don't* want to have to switch to a new major version of their entire base operating system to do it. With the PEP, opting in to PEP 476 for Python 2 applications and services is just a configuration file setting, readily managed with any configuration management tool. If just the configuration file approach is supported (as is the case for RHEL 7.2), then that decision needs to be made on a system-wide basis, and you need to use a chroot (or a full Linux container) in order to opt out (or in) for a single application. If the environment variable downgrade is also supported, then the environments for individual applications can be tweaked, even while the overall environment is upgraded to complain about missing security checks by default.