On 24 November 2015 at 11:59, Barry Warsaw <barry@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.
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
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. 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@gmail.com | Brisbane, Australia