This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients alex, barry, bkabrda, christian.heimes, doko, dstufft, janssen, lemburg, ncoghlan, pitrou, r.david.murray, rkuska, vstinner
Date 2015-05-08.23:40:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADiSq7ehdGutCL6iqEeQi6Au-w+V8J7__LtpV5B6Km1W4F+CYQ@mail.gmail.com>
In-reply-to <554D3A34.8090206@egenix.com>
Content
Right, the key here is to think like a system administrator, not a
developer. Most of those folks are downstream of redistributors (whether
commercial ones or community Linux distributions) and relying on one of two
things:

* tools using the system cert store for certificate validation (so they can
trust an internal CA automatically)
* tools not verifying certificates properly

The *right* answer on Linux is option one (which the system Python will be
configured to use by default), but even with tools like DogTag available as
open source, running your own internal CA properly is currently still a
pain, especially once you start accounting for all the hardware devices out
there with tragically bad certificate management. You can't just wave a
magic wand and suddenly have all your physical gear catch up to the modern
state of the art in SSL/TLS management as learned on the public internet -
it's a staged upgrade project where the risks of insider threats and other
perimeter compromises get traded off against the upgrade costs and
infrastructure stability risks. This *is* work that needs to be done given
the world we live in, but we also need to trust CIOs to appropriately
manage the upgrade plans for their own intranets.

It's not a coincidence that initiatives like Let's Encrypt are due to
launch this year, nor that Red Hat's started hiring people like Christian
to help integrate SSL certificate management directly into Linux identity &
authentication management - this stuff currently gets done badly because
it's *too hard* to do it right.

But in the meantime, admins upgrading Python *2.7* need a way to say "let
us decide what our highest priority infrastructure risks are, thank you
very much". They don't need that for Python 3, as it doesn't have the same
kind of large install base in environments where infrastructure
modernisation represents a major ongoing investment. That means "your
SSL/TLS certificate management must be in good order" can reasonably be a
gating criterion for Python 3, but we need a better solution for
redistributors and administrators when it comes to Python 2.7 upgrades.
History
Date User Action Args
2015-05-08 23:40:20ncoghlansetrecipients: + ncoghlan, lemburg, barry, doko, janssen, pitrou, vstinner, christian.heimes, alex, r.david.murray, bkabrda, dstufft, rkuska
2015-05-08 23:40:19ncoghlanlinkissue23857 messages
2015-05-08 23:40:19ncoghlancreate