[Linux-SIG] PEP 476 and backward incompatibilities for distros

[Barry Warsaw]

On Oct 09, 2015, at 04:24 AM, Nick Coghlan wrote:

>For upstream, working on PEP 466 persuaded me that the priority needs to be
>on providing safe defaults in order to minimise risks for new users, and
>for insufficiently paranoid existing users.

2.7 is a special case because there will never be a 2.8.  I think it's a
different calculus for Python 3.  If we hadn't broken backward compatibility
in 3.4.3 folks would have eventually gotten the change in 3.5.  That doesn't
eliminate the cost on developers for the compatibility break, but it does
defer it until they do general 3.5 compatibility work.  I'm also not convinced
that the good PR we might gain from providing users with a more secure default
offsets the PR hit we get for breaking compatibility in point releases.

It also gives me a vague anti-we're-all-adults feeling.

>The burden then falls on commercial redistributors to effectively manage
>backwards incompatible changes on behalf of our customers, rather than
>expecting upstream to prioritise our interests over those of the rest of
>the community.

"Effectively managing" could very well mean backing out the incompatible
change.  But as my larger point goes, that's may not actually be easy to do.
If we're going to break backward compatibility in point releases, we need to
advertise that loudly, make those changes auditable, and give people an easier
way to return to the previous compatible if insecure default.  Not all uses of
the default are by naive users who need our help to keep all their bases off
the intarwebs.

It's also not just downstream distros that could be adversely affected by such
changes.

>Providing a better migration path for cases where commercial support
>obligations apply is what the proposed PEP 493 recommendations are about:
>https://www.python.org/dev/peps/pep-0493/

The other thing to keep in mind is that distros generally have a team
dedicated to security issues.  Was this change in response to a CVE?
Certainly those teams are better able to judge the implications for the
insecure compatible default for users and applications on their platform.  I
don't envy the work they do to balance those backward compatibility issues
against increased security.

A change here by upstream is an end-around of those team's responsibilities.
Which might still mean it's the right decision for *Python* (and we can argue
that on python-dev) but it behooves us to make that very obvious for
downstream consumers who come out on the other side of that equation.

>This is on redistributors to handle - if we want more or different
>documentation in cases like these, then we need to be paying people to
>spend more time on representing our interests (and those of our users) in
>CPython upstream development, rather than focusing our efforts solely on
>integration work for our respective operating systems.

No, because as I said it doesn't only affect distros with paid employees.
Maybe it affects distros that are purely volunteer run.  Maybe it affects
people installing Python from source for their own internal usage.  Etc.

Upstream is who knows that a compatibility break is coming in a point
release.  We owe it to our users to first, be very careful about that, and
second to make sure that information is very well advertised.

>The perpetuation of bad default behaviours in the name of backwards
>compatibility is a large part of what turned our industry into the insecure
>user hostile mess that it is today, though.

So, we're going to have to break compatibility at some point to fix it.  The
question is where and when?  Buried in a point release?  Wait until the next
major release?  In documentation, a tech note, or announcement?

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/linux-sig/attachments/20151008/b1e22a29/attachment-0001.sig>