On Sun, 23 Mar 2014 07:11:07 +1000 Nick Coghlan <ncogh...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
