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

[Barry Warsaw]

On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote:

>I'm not a big fan of it either, but it's the way sustainable
>commercial open source distribution works in practice:

While it's inevitable that redistributors have to deviate from upstream, in
Debian and Ubuntu, we really try to keep that at a minimum.  Debian, of course
is an all volunteer organization so our "customers" are just normal users who
I think want an experience as close to installing from source as possible,
consistent with the principles and policies of the Debian project.  Debian at
least tries to document the handful of deviations from upstream.

Likewise in Ubuntu, we try to keep deviations from Debian at a minimum, and
document them when we must deviate.  Ubuntu is a community driven distro so
while Canonical itself has customers, it's much more likely that feedback
about the Python stack comes from ordinary users.  Again, my personal goal is
to make Python on Ubuntu a pleasant and comfortable environment, as close to
installing from source as possible, consistent with the principles and
policies of the project.

All this to say that IMHO, solutions to problems should go as far upstream as
possible.  Guidelines certainly are useful (e.g. PEP 394) to maintain
consistency across downstream providers where the decisions are primarily in
the sphere of influence of the downstreams, but IMHO there's still more that
upstream can do to promote PEP 493.

>Different redistributors have different customer bases, which also
>differ from the audience for upstream python.org releases, so saying
>"don't patch Python" is denying the reality of the obligations
>commercial vendors have to their customers, while "when you patch
>Python, please ensure you abide by these guidelines" is something
>redistributors can realistically do.

ISTM that the same forces are in play regardless of whether the change is in
code or in an informational PEP.  Best to get consensus where possible, and
manifest those decisions in code, but if competing goals are the outcome of a
code change or informational PEP, downstream consumers will still make what
they judge to be the best decision in the interest of their users, balanced
against their own competing constraints.

>In this particular case, the migration problems were already raised in
>the PEP 476 discussions, and the decision was made to *not* provide a
>public API specifically for globally turning off HTTPS certificate
>verification, since that would either:
>
>1. Need to be added to Python 3 and maintained indefinitely; or
>2. Be implemented in Python 2.7 only, and thus create another barrier
>to 2->3 migration

A minor one, for sure.  It wouldn't significantly bother me if the API were
underscore-prefixed as a big honkin' clue about the guarantees being made.

>* Robert Kuska came up with a way to do a backwards compatible
>backport of PEP 476 to RHEL 7.2 that doesn't raise any new barriers to
>migrating from Python 2 to Python 3

I'm not sure I agree with that.  If you have to set an environment variable to
get your application to work in Python 2.7, it's *still* a migration issue
when you move to Python 3.  You're just moving the change out of the code and
into the environment, where it's arguably more difficult to re-discover down
the road.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151126/8ffa6410/attachment.sig>