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

[Nick Coghlan]

On 24 November 2015 at 11:59, Barry Warsaw <barry at python.org> wrote:
> On Nov 24, 2015, at 10:18 AM, Nick Coghlan wrote:
>
>>Since we already know Red Hat are OK with the draft recommendations,
>>and I missed the RHEL 7.2 release date anyway, perhaps Barry or
>>Matthias might be interested in tilting at the Ubuntu 14.04 LTS stable
>>release update windmill? I know there was previously a decision from
>>Ubuntu Security not to backport PEPs 466 & 476 to 2.7.5 due to the
>>stability risks [1], but the configuration file based approach
>>recommended in PEP 493 is backwards compatible by default
>
> Right, but this isn't a patch we'd particularly want to carry ourselves.
> Maybe if it were available upstream, tried and tested, it could be considered
> for backporting, but it still wouldn't be zero cost.

If anyone wants to look through the patches implementing the backport,
they're available through the CentOS git repositories:
https://git.centos.org/commit/rpms!python.git/refs!heads!c7

> We'd have to also handle
> migration paths to newer Ubuntu releases, which probably means removing the
> config file on future upgrades.

You'll need to figure out those migration paths anyway, as the
certificate verification compatibility break will exist between 14.04
and 16.04 regardless of what happens with PEP 493.

> There's also the possibility of implementing
> different defaults on new installs of 14.04 versus upgrades to 14.04.

For those aspects, we left the defaults in RHEL 7.2 as implementing
the 2.7.5 behaviour (i.e. no cert verification), but used the
"platform default" mechanism in PEP 493 to ensure we had the ability
to change our mind if circumstances change.

For the immediately foreseeable future though, it will be up to
operations teams to decide how they want the Python 2.7 standard
library to behave with respect to HTTPS client certificate
verification on RHEL & CentOS 7.

> And
> even if a system administrator enabled it for one particular application, it
> could break other applications on the same machine, so it just punts a
> difficult decision down the line.
>
> We're also not seeing much (any?) demand from our users, and the initial
> attempt at turning this on by default *did* get a strong negative reaction
> because of the compatibility break.

My own main concern is providing an additional layer of defence
against certificate verification related security bugs in network
services and clients written in Python like OpenStack, Ansible,
FreeIPA, Pulp, etc, which is why I'm happy with the approach of giving
system operators the tools they need to make their own decision about
whether or not they want that additional layer of protection on a
given host. Folks building Docker images can also easily opt in or out
by including a suitable configuration file.

>From a change management perspective, there's also a very big
difference between "We made this decision for you, and you'll need to
update your systems accordingly in order to upgrade", and "We made it
possible for you to make your own decision about this new
configuration setting, based on what you think is best for your
particular situation".

There's still some risk in the latter case (since you may accidentally
break things), but the upstream releases flushed out a lot of those
problems for this particular update (e.g. the gevent compatibility
issue that affected the upstream PEP 466 backport).

Regards,
Nick.

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