On Mon, Nov 23, 2015 at 5:59 PM, Barry Warsaw <ba...@python.org> wrote:
> I'm concerned about accepting PEP 493 making a strong recommendation to > downstreams. Yes, in an ideal world we all want security by default, but I > think the backward compatibility concerns of the PEP are understated, > especially as they relate to a maintenance release of a stable long term > support version of the OS. I don't want PEP 493 to be a cudgel that people > beat us up with instead of having an honest discussion of the difficult > trade-offs involved. > It sounds like the implementation sections of the PEP are acceptable but that the PEP's general tone seems to assume that distributors are champing at the bit to backport and that the recommendations here make it so that backporting is a no-brainer -- which does not seem to reflect the real-world? I think the tone could be changed to address that as it doesn't seem like forcing distros to backport is a real goal of the PEP. The main purposes of the PEP seem to be: * Enumerate several ways that distributors can backport these 2.7.9 features to older releases * Allow programmers to detect the presence of the features from their code * Give end-users the ability to choose between backwards compatibility and enhanced security Here's some ideas for changing the tone: Abstract ======== PEP 476 updated Python's default handling of HTTPS certificates to be appropriate for communication over the public internet. The Python 2.7 long term maintenance series was judged to be in scope for this change, with the new behaviour introduced in the Python 2.7.9 maintenance release. + Change to "PEP 476 updated Python's default handling of HTTPS certificates to validate that the certs belonged to the server". This way we're saying what the change is rather than making a value judgement of whether people who don't choose to backport are "appropriate" or not. Appropriate-ness is probably best left as an argument in the text of PEP 476. This PEP provides recommendations to downstream redistributors wishing to provide a smoother migration experience when helping their users to manage this change in Python's default behaviour. + Change to "downstream redistributors wishing to backport the enhancements in a way that allows users to choose between backwards compatible behaviour or more secure certificate handling." As barry noted, this PEP doesn't change the amount of work needed to migrate. It does, however, give users some choice in when they are going to perform that work. Additionally, this isn't simply about distributors who want to make the transition smoother... (there's no downstreams that want to make it "more painful" are there? ;-) It's really about making backporting of the enhancements less painful for users. Rationale ========= PEP 476 changed Python's default behaviour to better match the needs and expectations of developers operating over the public internet, a category which appears to include most new Python developers. It is the position of the authors of this PEP that this was a correct decision. However, it is also the case that this change *does* cause problems for infrastructure administrators operating private intranets that rely on self-signed certificates, or otherwise encounter problems with the new default certificate verification settings. + per barry's mesage, it would be good to either devote a paragraph to the backwards compatibility implications here or link to https://www.python.org/dev/peps/pep-0476/#backwards-compatibility The long term answer for such environments is to update their internal certificate management to at least match the standards set by the public internet, but in the meantime, it is desirable to offer these administrators a way to continue receiving maintenance updates to the Python 2.7 series, without having to gate that on upgrades to their certificate management infrastructure. + The wording here seems to reflect a different scope than merely backporting by distros. Perhaps we should change it to: "[...]set by the public internet. Distributions may wish to help these sites transition by backporting the PEP 476 changes to earlier versions of python in a way that does not require the administrators to upgrade their certificate management infrastructure immediately. This would allow sites to choose to use the distribution suppiied python in a backwards compatible fashion until their certificate management infrastructure was updated and then toggle their site to utilize the more secure features provided by PEP 476." [...] These designs are being proposed as a recommendation for redistributors, rather than as new upstream features, as they are needed purely to support legacy environments migrating from older versions of Python 2.7. Neither approach is being proposed as an upstream Python 2.7 feature, nor as a feature in any version of Python 3 (whether published directly by the Python Software Foundation or by a redistributor). + This paragraph seems a little out of place here as it is not about why this PEP is useful so much as who will implement it. It also seems to tie into Abstract closely as it reinforces and expands on where this is going to make a difference. Perhaps move it to Abstract or create a "Scope" section that can follow abstract and contain this information. wording can be changed a bit to show that it isn't expected that all redistributors are expected to follow this but only those who are already backporting: "These recommendations are being proposed to redistributors who wish to backport PEP 476 features rather than as a new upstream feature as they are needed purely to support migrating legacy environments from older versions of python 2.7" -Toshio _______________________________________________ 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
