[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Mar 24 15:36:28 CET 2014

On 25 March 2014 00:18, Skip Montanaro <skip at pobox.com> wrote:

On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

For example, RHEL7 and derivatives are already locked in to 2.7 until 2024, RHEL6 and derivatives are locked in to 2.6 until 2020. The only way to keep those combination of RHEL and the Python 2 standard library from holding back the evolution of internet security standards is to find a way solve the problem within the 2.7 line in such a way that I can then make the case for also backporting it to 2.6 in a RHEL6 point release. Thanks for the explanation. I'm still a bit confused though. If there are backward compatibility issues with the proposed changes (whatever they turn out to be), are the commercial redistributors still going to balk at releasing these changes to their customers? From the reading I've done (this thread and your second iteration of the PEP), it seems like application developers will have to make some changes to take advantage of these updated security bits. Is there some path forward that really makes everything a drop-in improvement, requiring no change to application code, and breaking nothing that already works?

The PEP does not permit backwards compatibility breaks in maintenance releases, thus people are solely concerned about the increased risk of regressions created by backporting all of the Python 3 enhancements to these modules to Python 2.7 and then ensuring that the default behaviour remains the same as earlier Python 2.7 releases.

I think those folks have their priorities back to front, hence http://www.python.org/dev/peps/pep-0466/#handling-lower-security-environments-with-low-risk-tolerance :)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list