[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Antoine Pitrou
solipsis at pitrou.net
Sun Mar 23 01:01:38 CET 2014
On Sun, 23 Mar 2014 07:11:07 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> It is similar to the previous IDLE policy exception PEP, where we
> decided that cross version consistency of IDLE superseded the general
> policy against backporting enhancements to maintenance branches.
But the consequences are different: the stdlib promises API
stability between bugfix releases, while IDLE is a standalone
GUI application.
> This topic
> involves a complex balance between encouraging and supporting good
> security practices and limiting the risk of failures for users
> upgrading to new maintenance releases, so I'd ask that folks take time
> to read and consider the implications of the full PEP in the broader
> context of today's internet before posting comments on specific
> details, or indicating a preference one way or the other in terms of
> the overall proposal.
The fact that it involves a "complex balance" implies IMO that a
blanket exemption is the wrong mechanism, and instead the exemption
should probably be granted on a case-by-case basis.
> This PEP does *not* grant any general exemptions to the usual backwards
> compatibility policy for maintenance releases. Instead, it is designed
> to make it easier to provide more "secure by default" behaviour in future
> feature releases, while still limiting the risk of breaking currently
> working software when upgrading to a new maintenance release.
But enforcing "secure by default" can by construction break backwards
compatibility, which is the very reason we are so conservative with
such changes.
> Thus the focus on
> network security protocols and related cryptographic infrastructure -
This is a bit limited. There are remotely-exploitable security issues
which are still open on the bug tracker; they are not
cryptography-related, but that shouldn't make a difference.
(for example the dreaded XML issues have never been properly fixed,
AFAICT)
> My position on the ongoing transition from Python 2 to Python 3 has long
> been that Python 2 remains a supported platform for the core development
> team, and that commercial support will remain available well after upstream
> maintenance ends.
If this is about the difficulty of migrating to Python 3, then this PEP
should focus specifically on that problem, and restrict the policy to
Python 2.7. Upgrading from 3.X to 3.X+1 is easy, and so is
backporting patches from 3.X to 3.X-1, conversely.
> * Are there any other security relevant modules that should be covered
> by either a blanket or conditional exemption?
Every module can be remotely "security relevant", unfortunately.
Regards
Antoine.
More information about the Python-Dev
mailing list