[Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

[Nick Coghlan]

On 24 November 2015 at 12:05, Barry Warsaw <barry at python.org> 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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia