On Tue, Nov 24, 2015 at 10:56 AM, Paul Moore firstname.lastname@example.org wrote:
On 24 November 2015 at 18:37, Toshio Kuratomi email@example.com wrote:
The cornercases come into play because you don't always control all of the devices and services on your network. The site could evaluate and decide that MITM isn't a threat to their switch's configuration interface but that interface might be served over https using a certificate signed by their network vendor who doesn't give out their ca certificate (simply stated: your security team knows what they're doing but your vendor's does not).
This sounds like a similar situation to what I described above. I'm not sure I'd see these as corner cases, though - they are pretty much day to day business in my experience :-(
It sounds like you're coming from a Windows background and I'm coming from a Linux background which might be a small disconnect here -- we do seem to be in agreement that what's "right to do" isn't always easy or possible for the client to accomplish so I think we should probably leave it at that.
In my opinion, we should take all of the value judgements out of this paragraph, and just state the facts. How about:
""" In order to provide additional flexibility to allow infrastructure administrators to provide the appropriate solution for their environment, this PEP offers a way for administrators to upgrade to later versions of the Python 2.7 series without being forced to update their existing security certificate management infrastructure as a prerequisite. """
- python-2.7.9+ doesn't give you flexibility in this regard so
organizations do have to update their certificate management infrastructure. The cornercase described above becomes something that has to be addressed at the code level. Environments that are simply misconfigured have to be fixed. So in that regard, a value judgement does seem appropriate here. the judgement is "Listen guys, this PEP advises redistributors on how they might provide a migration path for you but it *does not bandaid the problem indefinitely*. So long term, you have to change your practices or you'll be out in the cold when your redistributor upgrades to python-2.7.9+"
Hmm, maybe I misread the PEP (I only skimmed it - as I say, Linux is of limited interest to me). I thought that the environment variable gave developers a "get out" clause. Maybe it's not what we want them to do (for some value of "we") but isn't that the point of the PEP?
Admittedly if distributions don't *implement* that part of the PEP (and I understand Red Hat haven't) then people are still stuck. But "this PEP offers a way" is not incompatible with "your vendor didn't implement the PEP so you're still stuck, sorry"...
Yeah, I think you are correct in your understanding of what actual changes to the python distrribution are being proposed for redistributors in the PEP. Reading through the PEP again, I'm not sure if I'm correct in thinking that this only applies to backporting... it may be that the environment section of the PEP applies to any python-2 while the config file section only applies to backporting. Nick, could you clarify?
The PEP is clear that it doesn't apply to python-3 or cross-distro. So that means that sites still can't rely on this long-term (but their long term would extend to the lifetime of their vendor supporting python2 rather than when their vendor updated to 2.7.9+) and also that developers can't depend on this if they're developing portable code.
- Your proposed text actually removes the fix that I was adding --
this version of the paragraph implies that if your environment is compatible with the redistributors' python-2.7.8 (or less) then it will also be compatible with the redistributors' python-2.7.9+. That is not true. Whether or not we take out any value judgement as to the user's present environment this paragraph needs to be fixed to make it clear that this only affects redistributor's packages which have backported pep 476 to python-2.7.8 or older. Once the redistributor updates to a newer python sites which relied on this crutch will break.
Sorry for that. Certainly getting the facts right is crucial, and it looks like my suggestion didn't do that. But hopefully someone can fix it up (if people think it's a good way to go).
Could be that I'm wrong -- will wait for Nick to clarify before I think about what could be done to make this wording better.