Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 26.03.2014 00:06, schrieb Nick Coghlan: On 26 Mar 2014 08:32, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Am 25.03.2014 23:15, schrieb Nick Coghlan: On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com mailto:bcan...@gmail.com mailto:bcan...@gmail.com mailto:bcan...@gmail.com wrote: As long as we make it clear we have chosen to change our backwards-compatibility guarantees in the name of security and have a link to the last backwards-compatible release then I agree as well. I am not sure how this meme got started, but let me be clear: the proposed policy DOES NOT provide blanket permission to break backwards compatibility in the affected modules. It only allows ADDING new features to bring these modules into line with their Python 3 counterparts, making it easier for third party packages like requests to do the right thing in a cross-version compatible way. We know. That's what we mean by that. That's not what Brett said - he called 2.7.6 the last backwards compatible release. That's not correct, as even under my proposal, 2.7.7+ will still be backwards compatible. Yeah, I took backwards-compatibility guarantees to also mean the no new features guarantee, but you're right that the two can be separated. Georg ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Wed Mar 26 2014 at 2:15:39 AM, Georg Brandl g.bra...@gmx.net wrote: Am 26.03.2014 00:06, schrieb Nick Coghlan: On 26 Mar 2014 08:32, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Am 25.03.2014 23:15, schrieb Nick Coghlan: On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com mailto:bcan...@gmail.com mailto:bcan...@gmail.com mailto:bcan...@gmail.com wrote: As long as we make it clear we have chosen to change our backwards-compatibility guarantees in the name of security and have a link to the last backwards-compatible release then I agree as well. I am not sure how this meme got started, but let me be clear: the proposed policy DOES NOT provide blanket permission to break backwards compatibility in the affected modules. It only allows ADDING new features to bring these modules into line with their Python 3 counterparts, making it easier for third party packages like requests to do the right thing in a cross-version compatible way. We know. That's what we mean by that. That's not what Brett said - he called 2.7.6 the last backwards compatible release. That's not correct, as even under my proposal, 2.7.7+ will still be backwards compatible. Yeah, I took backwards-compatibility guarantees to also mean the no new features guarantee, but you're right that the two can be separated. That's also the way I took it; not that code would be inherently broken from 2.7.0 - 2.7.x, but that the let's stay conservative and add *nothing* would stop being followed since something in 2.7.x wouldn't work in 2.7.0. IOW I expect (except maybe in extreme edge cases) that unmodified code would work across 2.7 as long as it works in 2.7.0 no matter what happens with this PEP. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 25 March 2014 12:25, MRAB pyt...@mrabarnett.plus.com wrote: On 2014-03-25 01:29, Ben Darnell wrote: On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com mailto:ros...@gmail.com wrote: As has already been pointed out, this can already happen, but in an ad-hoc way. Making it official or semi-official would mean that a script written for Debian's Python 2.7.10 would run on Red Hat's Python 2.7.10, which would surely be an advantage. And having it break on the official Windows and Mac OS X binaries would benefit end users, how? The position I am coming to is that the enhanced security release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do Python 2.7 with legacy SSL releases if they so choose. I'm happier forcing end users to rely on a redistributor to opt in to a lower security option than I am to knowingly publish too many additional releases with network security infrastructure that is (at best) rapidly approaching its use by date. I am strongly against allowing downstream distributors that choice. Unless the security-enhanced variant of Python 2.7 quickly and completely overtakes all previous versions, we will be creating a compatibility problem between the two variants of Python 2.7. I believe that the changes motivating this PEP can be made with minimal backwards-incompatibility risk and (if the PEP is accepted) we should use all the leverage at our disposal to drive adoption. The risk is not backwards incompatibility, it is ambiguity of what Python 2.7 means. If changes under this PEP would result in any distributors rationally remaining at Python 2.7.6, then the result of any such changes should be labelled Python 2.8. I think that calling it Python 2.8 would be a bad idea for the reasons that have already been stated. Perhaps it should just be called Python 2.7 Enhanced Security (Python 2.7 ES). The PEP currently calls the proposed unmodified fork of 2.7 Python 2.7 with Legacy SSL. I suspect we could potentially ask the PSF to enforce that from a trademark perspective (that is, redistributors wouldn't be allowed to call versions with the legacy infrastructure Python 2.7, they'd have to include the with Legacy SSL qualifier - that would also encompass all redistributions of 2.7.6 and below). I'm actually personally OK with just making vendors do all the work if they're really so worried about a slightly increased chance of undetected regressions that they prefer to keep using older SSL infrastructure. I think persisting with the old SSL infrastructure for too much longer would be a fundamentally bad idea, so I don't mind at all making it more difficult for downstream redistributors to do so. As Ben notes, allowing them this option increases the chance of confusion about what Python 2.7 means, and once an upgrade Python 2.7 release was published, the Python 2.7 with Legacy SSL moniker would apply just as well to Python 2.7.6 and earlier as it would to a hypothetical additional branch that would impose an ongoing maintenance burden upstream. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 25.03.2014 08:51, schrieb Nick Coghlan: I think that calling it Python 2.8 would be a bad idea for the reasons that have already been stated. Perhaps it should just be called Python 2.7 Enhanced Security (Python 2.7 ES). The PEP currently calls the proposed unmodified fork of 2.7 Python 2.7 with Legacy SSL. I suspect we could potentially ask the PSF to enforce that from a trademark perspective (that is, redistributors wouldn't be allowed to call versions with the legacy infrastructure Python 2.7, they'd have to include the with Legacy SSL qualifier - that would also encompass all redistributions of 2.7.6 and below). I don't know. It still feels like a source of confusion all round to have two different (C)Pythons not distinguished by version number. I haven't followed all of this thread, so forgive me if this suggestion has come up already: Since we know the EOL of 2.7, can't we say there won't be any more non-secure bugfix releases than up to 2.7.9, and the namespace 2.7.10 (yeah I know, but still way better than 2.8) and above is free for the new SSL versions. This also works from a version requirement point of view: if you require Python = 2.7.10 you know you'll get the new features. If you don't, you shouldn't be using (or carefully checking) the new opt-in features. I'm actually personally OK with just making vendors do all the work if they're really so worried about a slightly increased chance of undetected regressions that they prefer to keep using older SSL infrastructure. I think persisting with the old SSL infrastructure for too much longer would be a fundamentally bad idea, so I don't mind at all making it more difficult for downstream redistributors to do so. I agree, if no other solution can be found we should err on the secure side (as opposed to the safe side). Georg ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Tue, Mar 25, 2014 at 7:12 PM, Cory Benfield c...@lukasa.co.uk wrote: On 24 March 2014 19:37, Chris Angelico ros...@gmail.com wrote: The opting in could be done at the distro level. Red Hat could ship a thing called /usr/bin/python that runs SEPython, and that package could be identified and numbered in such a way that it's clearly a drop-in replacement for vanilla Python. If backward compatibility is done carefully (which, from everything I'm seeing here, is the way it's to be done), there should be absolutely no downside to using SEPython, except for portability (because now you're depending on it for security), and corner cases like testing. What's your solution for OS X, Windows et al? My concern is that if you have a release called 'Python' and a release called 'Python with security stuff', a surprisingly large number of people will download the first, especially if the notes for the security release say 'this may cause some minor compatibility problems'. IMHO, I'd rather have good security be the default for everyone, and require an explicit opt-out to get the bad security release. Exactly the same. If someone wants to distribute SEPython (that someone might be python.org itself, or ActiveState, or anyone else who has an interest in it), they're welcome to do so; and it could be done either as an all-in-one that packages all of CPython, or as an add-on; either way would work just as well, but the former would be cleaner. ChrisA ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Tue, Mar 25, 2014 at 7:37 PM, Cory Benfield c...@lukasa.co.uk wrote: On 25 March 2014 08:26, Chris Angelico ros...@gmail.com wrote: Exactly the same. If someone wants to distribute SEPython (that someone might be python.org itself, or ActiveState, or anyone else who has an interest in it), they're welcome to do so; and it could be done either as an all-in-one that packages all of CPython, or as an add-on; either way would work just as well, but the former would be cleaner. Reading this I suspect we're mostly in agreement but having trouble communicating. My understanding of your point is simply that you don't want python-dev to 'bless' either of the 2.7 releases proposed as _the_ 2.7 release, instead pushing that choice on to people distributing Python. I can get behind that plan so long as the source code releases are named in such a way that people are either a) forced to make a choice; or b) defaulted to secure 2.7. I'd like python.org / python-dev to bless, if not some specific version, at least some specific structure. I think that's something like what has been in the PEP at some point, though I haven't dug into the current version deeply enough to be sure. But if you take current 2.7 as a baseline, every new feature would be implemented by creating a new attribute of either the ssl module or some class in it; if the attribute is there, you can use it (eg a constant/enum value that's a parameter to something else), and if it's not, you can't. As long as the names are consistent, it'd be easy for a program to either probe and use what it can get, or just use what it wants and bomb if you don't give it a sufficiently-secure Python. So by that model, current 2.7 is fully compliant, and anything that doesn't actively conflict with that is also compliant. Any script that is written for the current 2.7 is guaranteed also to run on any compliant SEPython; and anything written for SEPython has to gracefully handle (which might mean cleanly bombing) anything down to and including current 2.7. Does that make sense? ChrisA ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 25 March 2014 08:26, Chris Angelico ros...@gmail.com wrote: Exactly the same. If someone wants to distribute SEPython (that someone might be python.org itself, or ActiveState, or anyone else who has an interest in it), they're welcome to do so; and it could be done either as an all-in-one that packages all of CPython, or as an add-on; either way would work just as well, but the former would be cleaner. Reading this I suspect we're mostly in agreement but having trouble communicating. My understanding of your point is simply that you don't want python-dev to 'bless' either of the 2.7 releases proposed as _the_ 2.7 release, instead pushing that choice on to people distributing Python. I can get behind that plan so long as the source code releases are named in such a way that people are either a) forced to make a choice; or b) defaulted to secure 2.7. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 24 March 2014 19:37, Chris Angelico ros...@gmail.com wrote: The opting in could be done at the distro level. Red Hat could ship a thing called /usr/bin/python that runs SEPython, and that package could be identified and numbered in such a way that it's clearly a drop-in replacement for vanilla Python. If backward compatibility is done carefully (which, from everything I'm seeing here, is the way it's to be done), there should be absolutely no downside to using SEPython, except for portability (because now you're depending on it for security), and corner cases like testing. What's your solution for OS X, Windows et al? My concern is that if you have a release called 'Python' and a release called 'Python with security stuff', a surprisingly large number of people will download the first, especially if the notes for the security release say 'this may cause some minor compatibility problems'. IMHO, I'd rather have good security be the default for everyone, and require an explicit opt-out to get the bad security release. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 25 March 2014 09:01, Chris Angelico ros...@gmail.com wrote: So by that model, current 2.7 is fully compliant, and anything that doesn't actively conflict with that is also compliant. Any script that is written for the current 2.7 is guaranteed also to run on any compliant SEPython; and anything written for SEPython has to gracefully handle (which might mean cleanly bombing) anything down to and including current 2.7. Does that make sense? Absolutely. =) My additional concern on top of that is wanting users to fall into a pit of success by making it overwhelmingly more likely that users will accidentally end up with the safe version if they aren't paying attention. I'm not hugely bothered about how that's done: I'd just like not to have to field Requests bug reports about lack of security that boil down to a user having grabbed the insecure version by accident. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Tue Mar 25 2014 at 4:21:51 AM, Georg Brandl g.bra...@gmx.net wrote: Am 25.03.2014 08:51, schrieb Nick Coghlan: I think that calling it Python 2.8 would be a bad idea for the reasons that have already been stated. Perhaps it should just be called Python 2.7 Enhanced Security (Python 2.7 ES). The PEP currently calls the proposed unmodified fork of 2.7 Python 2.7 with Legacy SSL. I suspect we could potentially ask the PSF to enforce that from a trademark perspective (that is, redistributors wouldn't be allowed to call versions with the legacy infrastructure Python 2.7, they'd have to include the with Legacy SSL qualifier - that would also encompass all redistributions of 2.7.6 and below). I don't know. It still feels like a source of confusion all round to have two different (C)Pythons not distinguished by version number. I haven't followed all of this thread, so forgive me if this suggestion has come up already: Since we know the EOL of 2.7, can't we say there won't be any more non-secure bugfix releases than up to 2.7.9, and the namespace 2.7.10 (yeah I know, but still way better than 2.8) and above is free for the new SSL versions. This also works from a version requirement point of view: if you require Python = 2.7.10 you know you'll get the new features. If you don't, you shouldn't be using (or carefully checking) the new opt-in features. Or if this is such a big deal we start with 2.7.6 and not postpone until 2.7.10 (which I guess could happen immediately after 2.7.9 and have nothing more than the upgraded modules). People have been making grandiose statements about how the security of the internet is hampered by Python 2.7 in this discussion. If these statements are actually not over-stated then we should do the fix sooner *and* add the incentive people to switch over by getting more bug fixes. It's not like Python 2.7 is getting a ton of fixes at this point anyway. I'm actually personally OK with just making vendors do all the work if they're really so worried about a slightly increased chance of undetected regressions that they prefer to keep using older SSL infrastructure. I think persisting with the old SSL infrastructure for too much longer would be a fundamentally bad idea, so I don't mind at all making it more difficult for downstream redistributors to do so. I agree, if no other solution can be found we should err on the secure side (as opposed to the safe side). As long as we make it clear we have chosen to change our backwards-compatibility guarantees in the name of security and have a link to the last backwards-compatible release then I agree as well. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com wrote: As long as we make it clear we have chosen to change our backwards-compatibility guarantees in the name of security and have a link to the last backwards-compatible release then I agree as well. I am not sure how this meme got started, but let me be clear: the proposed policy DOES NOT provide blanket permission to break backwards compatibility in the affected modules. It only allows ADDING new features to bring these modules into line with their Python 3 counterparts, making it easier for third party packages like requests to do the right thing in a cross-version compatible way. The use feature detection, not version checks guidelines in the PEP are designed to deal with the concerns around subsequently missing features in the existing Python 2.7 releases. The remaining concern appears to be largely around the slightly increased chance of regressions that comes with making larger changes to these modules in order to incorporate the new features. Given our regression test suite, and those of other projects like OpenStack and components of the Linux distributions, I now consider that concern to be entirely misplaced. The only backwards compatibility breaks allowed general exemption applies to the new ssl.create_default_context() function, which *is* defined as allowing backwards incompatible changes to keep up with evolving security requirements. That exemption is in the documentation of that API, though - the only impact of this PEP would be to also make that API available in 2.7.7+. Regards, Nick. ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 25.03.2014 23:15, schrieb Nick Coghlan: On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com mailto:bcan...@gmail.com wrote: As long as we make it clear we have chosen to change our backwards-compatibility guarantees in the name of security and have a link to the last backwards-compatible release then I agree as well. I am not sure how this meme got started, but let me be clear: the proposed policy DOES NOT provide blanket permission to break backwards compatibility in the affected modules. It only allows ADDING new features to bring these modules into line with their Python 3 counterparts, making it easier for third party packages like requests to do the right thing in a cross-version compatible way. We know. That's what we mean by that. Georg ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 26 Mar 2014 08:32, Georg Brandl g.bra...@gmx.net wrote: Am 25.03.2014 23:15, schrieb Nick Coghlan: On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com mailto:bcan...@gmail.com wrote: As long as we make it clear we have chosen to change our backwards-compatibility guarantees in the name of security and have a link to the last backwards-compatible release then I agree as well. I am not sure how this meme got started, but let me be clear: the proposed policy DOES NOT provide blanket permission to break backwards compatibility in the affected modules. It only allows ADDING new features to bring these modules into line with their Python 3 counterparts, making it easier for third party packages like requests to do the right thing in a cross-version compatible way. We know. That's what we mean by that. That's not what Brett said - he called 2.7.6 the last backwards compatible release. That's not correct, as even under my proposal, 2.7.7+ will still be backwards compatible. Cheers, Nick. Georg ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 3/25/2014 6:15 PM, Nick Coghlan wrote: I am not sure how this meme got started, but let me be clear: the proposed policy DOES NOT provide blanket permission to break backwards compatibility in the affected modules. It only allows ADDING new features to bring these modules into line with their Python 3 counterparts, making it easier for third party packages like requests to do the right thing in a cross-version compatible way. I think the problem is that 'no new features' covers two quite different types of 'new' lumped together: change-new and new-new. New-new adds something completely new and does not break any sensible behavior that we worry about. We freely add new-new features with each new version. We do not add them to maintenance releases because then maintenance releases would be new versions. There are also considerations of incubation time, and the increased possibility of regressions with candidate-release versus alpha-beta-candidate-release schedules. Change-new additions changing existing behavior (like changing a default) and can therefore break code that we care about. Even for new versions, we are wary them and may require deprecation. One of the ironies of change-new is that it is much more similar to change-fix, which is allowed as maintenance, than new-new is. The tracker controversies are about issues on the borderline between change-fix and change-new. The original version of the PEP reference 434 as precedent. While partly valid, the reference could have fed the confusion because 434 does not draw the distinction given above. Indeed, part of the point of the PEP is that separating change-fix from change-new is difficult. As far as regressions go, a big new-new patch touching several untested modules worries me more than a small change-??? patch tweaking something in only one module, especially after writing tests for the module. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com wrote: As has already been pointed out, this can already happen, but in an ad-hoc way. Making it official or semi-official would mean that a script written for Debian's Python 2.7.10 would run on Red Hat's Python 2.7.10, which would surely be an advantage. And having it break on the official Windows and Mac OS X binaries would benefit end users, how? The position I am coming to is that the enhanced security release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do Python 2.7 with legacy SSL releases if they so choose. I'm happier forcing end users to rely on a redistributor to opt in to a lower security option than I am to knowingly publish too many additional releases with network security infrastructure that is (at best) rapidly approaching its use by date. Cheers, Nick. ChrisA ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mon, Mar 24, 2014 at 7:44 PM, Nick Coghlan ncogh...@gmail.com wrote: On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com wrote: As has already been pointed out, this can already happen, but in an ad-hoc way. Making it official or semi-official would mean that a script written for Debian's Python 2.7.10 would run on Red Hat's Python 2.7.10, which would surely be an advantage. And having it break on the official Windows and Mac OS X binaries would benefit end users, how? It wouldn't. And if python.org doesn't publish a Windows binary, then either the exact same thing will happen, or there'll be one unofficial SEPython-like build. With only a semi-official SEPython 2.7.10, there could still be installers for all platforms - if nothing better, a two-stage installer that fires off the unchanged one and then plonks its own files elsewhere. The position I am coming to is that the enhanced security release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do Python 2.7 with legacy SSL releases if they so choose. I'm happier forcing end users to rely on a redistributor to opt in to a lower security option than I am to knowingly publish too many additional releases with network security infrastructure that is (at best) rapidly approaching its use by date. That's how it'd be with an official 2.7 security-enhanced release, and that would be fine. But even not going that far would have its benefit; as long as there's a clear definition of what SEPython 2.7.10 (or whatever it's called) is, a source-only release of those files would at least help to unify what would otherwise be a mess. But going the whole way and making a binary installer for an enhanced-security Python would definitely unify it a lot more. ChrisA ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sun, Mar 23, 2014 at 7:03 PM, Barry Warsaw ba...@python.org wrote: I want to stick to our no-Python-2.8 pledge I don't understand this dogmatic adherence to a no 2.8 pledge. Back when it was made, I don't think the issue of SSL vulnerabilities was understood (at least not to the current level). Now we're in a pickle. We need to find some way to release something that brings the SSL (and related) feature set up-to-date. In this thread and Nick's PEP have read about a few ways this might be accomplished (I probably missed a couple): * separate the security-dependent bits out into a separate semi-stdlib which would be served from PyPI * continue with 2.7.x but admit that there will be some possible backward incompatibilities with earlier 2.7 versions in the affected modules * change the name somehow and jump to two-digit micro version numbers It seems to me the PyPI option should be a non-starter, as it's unlikely that you will get the bulk of the 2.7 installations to update to that version, and if people do install it, they wind up with possible backward incompatibilities. The second option goes against the drop-in history of micro releases. The third seems just like weasel words to avoid saying 2.8. Also, a careful reading of the Zen of Python suggests these solutions might violate a number of its aphorisms (explicit is better than implicit, simple is better than complex, practicality beats purity). So what's the big deal? Why can't we be pragmatic and call this thing (whatever it turns out to be) 2.8? Is this pledge and its rationale written down in a PEP somewhere, so I can study the reasons behind what appears at this point to be blind adherence? Did someone administer a blood oath at a recent PyCon? Pledge-be-damned-ly y'rs, Skip ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 24 March 2014 23:49, Skip Montanaro s...@pobox.com wrote: So what's the big deal? Why can't we be pragmatic and call this thing (whatever it turns out to be) 2.8? Is this pledge and its rationale written down in a PEP somewhere, so I can study the reasons behind what appears at this point to be blind adherence? There's a ton of work involved in creating a new feature release, and there's no way we're going to go through that much drudgery for the legacy Python 2 series without someone paying for it. Even the more limited network security infrastructure update proposal in this PEP is conditional on corporate contributors agreeing to do the heavy lifting. Did someone administer a blood oath at a recent PyCon? As discussed in the PEP, a Python 2.8 release wouldn't actually solve this problem, so there's no reason for commercial redistributors to contribute to making it happen. 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. I think the proposal currently in round 3 of the PEP is something I can sell to the Platform Engineering team as a necessary update to make in a relatively timely fashion (I don't think the situation is critical yet, but give it another year or two and I'll be a lot more concerned). By contrast, trying to handle this via a Python 2.8 release would mean I would still have to advocate for us to adopt the policy in the PEP independently of upstream, and that's not a good outcome for anyone. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan ncogh...@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? Skip ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sun, 23 Mar 2014 21:31:12 -0400, Barry Warsaw ba...@python.org wrote: On Mar 24, 2014, at 11:38 AM, Chris Angelico wrote: Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the standard lib. Then you can go back to the standard 2.7 (if you want to) by unsetting PYTHONPATH. It'd be nice if SEPython defined a modified sys.version for clarity, but otherwise, it'd be a vanilla Python 2.7. That's certainly more in the direction of what I think is an appropriate upstream solution. The thing is, there isn't one single what's best for users resolution. There are many, many competing requirements and I think it will be difficult to satisfy everyone. I'm particularly sensitive to complaints of unexpected changes between micro releases. In the context of that last sentence, I think it is worth noting the stance that 3.4 is taking[*] about security backward compatibility, since many people may not be aware of it (we only just finished making the documentation clear). If you use create_default_context() to get your context object, you get a best practices level of security *that may change between maintenance releases*. If you want things to not change between maintenance releases, you create your own context object and set its controls appropriately. In other words, the programmer opts in to maintenance release security improvements by using create_default_context. I presume that whatever comes out of this PEP will use the same approach. Note: thanks again to Christian Heimes and Antoine Pitrou for this work. Without Christian's work, I think we wouldn't even be having this conversation. Antoine's earlier work laid essential groundwork, but by itself I'm not sure that would have been enough to result in calls for a backport. It took both of them, with some help from others as well. --David [*] I actually don't know if this was discussed on python-dev previously because I've got a backlog of messages I'm not caught up on. If it hasn't been, then doubly good to mention it now, since the first 3.4 maintenance release hasn't happened yet :) ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 25 March 2014 00:18, Skip Montanaro s...@pobox.com wrote: On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 25 March 2014 00:36, Nick Coghlan ncogh...@gmail.com wrote: On 25 March 2014 00:18, Skip Montanaro s...@pobox.com wrote: The PEP does not permit backwards compatibility breaks in maintenance releases Well, ssl.create_default_context() will use the same this is a dynamic best practices API policy as it does in 3.4. But everything that already exists in 2.7.6 will remain compatible with that behaviour by default. The policy change in the PEP won't automagically make networked software secure - it will just make it a heck of a lot *easier* to write in Python 2 (or the common subset of Python 2 and Python 3) by backporting the Python 3.4 enhancements to a 2.7 maintenance release, and, depending on the relative timing of the releases, likely the Python 3.5 enhancements to a later maintenance release. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 24 March 2014 08:44, Nick Coghlan ncogh...@gmail.com wrote: The position I am coming to is that the enhanced security release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do Python 2.7 with legacy SSL releases if they so choose. I'm happier forcing end users to rely on a redistributor to opt in to a lower security option than I am to knowingly publish too many additional releases with network security infrastructure that is (at best) rapidly approaching its use by date. I'm with you here Nick, the default should really be Python 2.7 with working TLS, not Python 2.7 with broken TLS (my only-slightly tongue-in-cheek proposed names for the releases). My concern with having Chris' proposal of an opt-in SEPython release is about discovery. I suspect most people will never find out about the SEPython release, meaning that most people will remain on insecure Python 2.7 distributions. If that happens, requests is essentially required to continue to support our current TLS model for 2.7 for as long as we support 2.7, and this PEP would give us no benefit at all. We're obviously not the only stakeholder here, but it's worth noting. Cory ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Le 24/03/2014 15:21, R. David Murray a écrit : In the context of that last sentence, I think it is worth noting the stance that 3.4 is taking[*] about security backward compatibility, since many people may not be aware of it (we only just finished making the documentation clear). If you use create_default_context() to get your context object, you get a best practices level of security *that may change between maintenance releases*. If you want things to not change between maintenance releases, you create your own context object and set its controls appropriately. Indeed. Note that this works because create_default_context() is a new API, hence it was ok to choose this particular maintenance policy. Maintenance policy of 3.4 as a whole (i.e. all other APIs) hasn't changed. (but some other aspects of SSL configuration, e.g. the default cipher list, is also amenable to changes in bugfix releases, as Donald's latest commits exemplify; in this case it should stay within the limits of reasonable backwards compatibility, i.e. not break any common use case) 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mon, Mar 24, 2014 at 8:28 PM, Cory Benfield c...@lukasa.co.uk wrote: On 24 March 2014 08:44, Nick Coghlan ncogh...@gmail.com wrote: The position I am coming to is that the enhanced security release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do Python 2.7 with legacy SSL releases if they so choose. I'm happier forcing end users to rely on a redistributor to opt in to a lower security option than I am to knowingly publish too many additional releases with network security infrastructure that is (at best) rapidly approaching its use by date. I'm with you here Nick, the default should really be Python 2.7 with working TLS, not Python 2.7 with broken TLS (my only-slightly tongue-in-cheek proposed names for the releases). My concern with having Chris' proposal of an opt-in SEPython release is about discovery. I suspect most people will never find out about the SEPython release, meaning that most people will remain on insecure Python 2.7 distributions. If that happens, requests is essentially required to continue to support our current TLS model for 2.7 for as long as we support 2.7, and this PEP would give us no benefit at all. We're obviously not the only stakeholder here, but it's worth noting. The opting in could be done at the distro level. Red Hat could ship a thing called /usr/bin/python that runs SEPython, and that package could be identified and numbered in such a way that it's clearly a drop-in replacement for vanilla Python. If backward compatibility is done carefully (which, from everything I'm seeing here, is the way it's to be done), there should be absolutely no downside to using SEPython, except for portability (because now you're depending on it for security), and corner cases like testing. Alternatively, it can be done as a separate package: install python to get Python, and install python-security-patches or python-tls to get the tweaks - once that's installed, /usr/bin/python becomes SEPython. Programs can depend on that package to ensure security. That does have a partial discoverability problem (possibly even worse, as you could test on a computer that has x, y, z installed, and then deploy on a brand new computer, and nothing there ever depended on SEPython, so you're vulnerable without knowing why), but that could be ameliorated by simply advising people to type yum install python-tls if they want to run any Python programs that use TLS. But I'd be inclined to the first option; its biggest downside is that installing python installs something other than the standard stdlib, which IMO isn't a big problem if (a) it's 100% backward compatible, and (b) it's semi-official anyway. ChrisA ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan ncogh...@gmail.com wrote: On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com wrote: As has already been pointed out, this can already happen, but in an ad-hoc way. Making it official or semi-official would mean that a script written for Debian's Python 2.7.10 would run on Red Hat's Python 2.7.10, which would surely be an advantage. And having it break on the official Windows and Mac OS X binaries would benefit end users, how? The position I am coming to is that the enhanced security release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do Python 2.7 with legacy SSL releases if they so choose. I'm happier forcing end users to rely on a redistributor to opt in to a lower security option than I am to knowingly publish too many additional releases with network security infrastructure that is (at best) rapidly approaching its use by date. I am strongly against allowing downstream distributors that choice. Unless the security-enhanced variant of Python 2.7 quickly and completely overtakes all previous versions, we will be creating a compatibility problem between the two variants of Python 2.7. I believe that the changes motivating this PEP can be made with minimal backwards-incompatibility risk and (if the PEP is accepted) we should use all the leverage at our disposal to drive adoption. The risk is not backwards incompatibility, it is ambiguity of what Python 2.7 means. If changes under this PEP would result in any distributors rationally remaining at Python 2.7.6, then the result of any such changes should be labelled Python 2.8. -Ben Cheers, Nick. ChrisA ___ 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/ncoghlan%40gmail.com ___ 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/ben%40bendarnell.com ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23.03.2014 02:33, Brett Cannon wrote: Now I have been reading this thread on my phone and I only have cursory understanding of what failure ssl has had as of late, so this might be stupid, but what if in Python 3.5 we made it so people passed in an explicit SSL object into the relevant APIs and threw an exception if one wasn't provided when trying to access something requiring SSL? Then the ssl module would start existing on PyPI to make sure it can evolve faster than every 18 months? I want to deprecate all SSL-related arguments except for the context argument. Several modules still except key and cert parameters. Do you want to make the context parameter a required parameter? ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Hi, 2014-03-22 22:11 GMT+01:00 Nick Coghlan ncogh...@gmail.com: In particular, the exception will apply to: * the ``ssl`` module * the ``hashlib`` module * the ``hmac`` module * the ``sha`` module (Python 2 only) * the components of other networking modules that make use of these modules * the components of the ``random`` and ``os`` modules that are relevant to cryptographic applications * the version of OpenSSL bundled with the binary installers The current Python development cycle is too slow to track latest security recommandations. Python 2.7 is now very far from Python 3.4, so backportng so many features is very complex and error-prone. IMO A third-party module backporting all these security enhancements would be easy to develop. There are already M2Crypto, cryptography and PyOpenSSL modules for example. You may reuse them. The drawback is that applications would be benefit immediatly from this work, they should be modified to use the new module. But usually, developers who care of security are able to do these modifications. The PEP is very generic. Can you try to list all missing security features of old Python versions? Victor ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Hi, 2014-03-23 11:17 GMT+01:00 mar...@v.loewis.de: Quoting Victor Stinner victor.stin...@gmail.com: The drawback is that applications would be benefit immediatly from this work, they should be modified to use the new module. But usually, developers who care of security are able to do these modifications. I think asking developers to make significant modifications to their code is besides the point of the PEP. I expect something like replacing import ssl with from safestdlib import ssl, same for other modules. FYI I backported some Python 3.3 modules for Python 2.7 for my Trollius project, and it was not so hard. For ssl.SSLContext, it's an empty class, it's just a wrapper to ssl.wrap_socket() which raises errors when unsupported features are used. http://trollius.readthedocs.org/#backports I wrote Trollius to port OpenStack to Python 3, not to defer the port :-) However, if they are willing to make changes, I'd still recommend that they port their code to Python 3, as that is the better long-term investment. It's not always possible. For example, the OpenStack projet still have +30 dependencies which are not Python 3 compatible yet. https://wiki.openstack.org/wiki/Python3#Dependencies We are porting these dependencies, but it may still take one year to port the whole OpenStack project to Python 3. Come to help us :) Sorry, it's maybe not fair to take the worst example (OpenStack) :-) Victor ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 Mar 2014 20:33, Victor Stinner victor.stin...@gmail.com wrote: Sorry, it's maybe not fair to take the worst example (OpenStack) :-) I suspect the Fedora/RHEL/CentOS ecosystem is going to make OpenStack look like a relatively simple port, and backwards compatibility constraints mean that already defined RHEL/CentOS releases simply won't be forward ported at all. I confess I hadn't fully connected the relevant dots until after writing the PEP this weekend, so I think I'm going to be having some interesting conversations with colleagues about that over the next couple of weeks and at PyCon :) Cheers, Nick. Victor ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy tjre...@udel.edu wrote: The download page for the final 2.7.z maintenance release could say something like We recommend that you move to the most recent Python 3 version if at all possible. If you cannot do that and you want to use Python to run a server on the public internet, we urge you to instead use the latest version of ServerPython 2.7.1s. This series is based on Python 2.7.z but has been and will continue to be enhanced with security features backported from Python 3. I'm unclear how this would be better than just biting the bullet and making a 2.8 release. On the one hand, the 2.7.x number suggests (based on the existing release protocol) that it should be a drop-in replacement for earlier 2.7 micro releases. On the other hand, calling it something like ServerPython implies that it's not necessary for network client applications, when, if I read the PEP correctly, it most certainly would be. If you create a 2.8 release which is restricted to just the topic areas of the PEP (that is, no other stuff backported from 3.x, no requirement to add other non-security bug fixes, etc), the incremented minor version number tells people that a bit of extra care is required to upgrade. The lack of change in the code base outside the security apparatus should make update pretty trivial for most every non-networked application. If the PEP or something like it is approved, the work is still going to have to be done, no matter what you call it. Why not be transparent about it? Skip ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 22 March 2014 21:11, Nick Coghlan ncogh...@gmail.com wrote: Full PEP included inline below, and available in more readable form at http://www.python.org/dev/peps/pep-0466/ Disclaimer: I pretty much don't use 2.x, or write server-type software, so my practical requirement for the changes proposed here is negligible. Having thought about the points in the discussion so far, it seems to me: 1. The only real issue is 2.7, so the PEP should limit itself to how do we deal with 2.7. 2. The PEP talks vaguely about commercial support for the security changes. I'm not quite sure what's being said here - I suspect Nick has some concrete input from Red Hat here, but he's trying to keep from being too specific in the PEP. I don't think that's necessarily helpful. If the proposal is Companies who want backported security features can provide patches and this is how python-dev will evaluate them then let's say that. At the moment, there's a feel in the PEP that python-dev are proposing to do the backports, and I'm not sure that's true. As written, the PEP risks exposing python-dev to accusations of not having delivered the improved security that the PEP promises. 3. If companies want specific security enhancements, there's nothing to stop them developing a patch, writing a PEP and proposing it to python-dev. The first such patch would trigger pretty much the current debate (is it OK to add an enhancement to 2.7, because it is for security reasons?) but with the benefit of being about something specific. Further proposals along the same lines could reference the first PEP as justification for allowing subsequent security enhancements. 4. A process like that described in (3) could happen right now. Why isn't it? Presumably the need for such enhancements is there (or there'd be no need for this PEP) so is it simply that companies like Red Hat don't know that they have this option? Would it be better simply to publish something explaining How commercial vendors can work with python-dev to deliver long-term support of Python 2.7.? 5. If the driver for this is Linux vendor support for 2.7, who is going to provide the Windows/OSX/Solaris/etc implementations of new features? Is nobody (implying that new features could end up being Linux-only) an acceptable answer? Will the burden of adding cross-platform support be on python-dev? Will patches be rejected unless they cover all supported platforms (and will this be an unacceptable burden for companies like Red Hat to take on)? The situation with Python 2.7 has been understood for many years now. Individual end users may not have thought through the implications and we have a responsibility to support them. But companies like Red Hat[1] are fully aware of their own release cycles, and the position with Python 2.x is public knowledge. They have to take some share of the blame for not planning for this situation (and they have paying customers who expect them to handle this, unlike python-dev). One problem here is that it's not at all clear what counts as dealing with a commercial vendor means in the context of enhancements (security or otherwise) to Python. We already have a route that's open to anyone, so what else is needed? And why? Most of the above is directed at the commercial vendors can help out aspect of the PEP. With regard to the wider suggestion that security enhancements be allowed for 2.7, we've been debating similar questions in various forms for *ages*. There's been talk of a 2.8 release. There have been ongoing discussions about helping people move to Python 3. There have been many discussions about whether it's OK for applications to remain on Python 2.7 (all of which said yes, it's fine - maybe the security fix aspect makes that statement a little less clear-cut). The fact that we haven't felt the need thus far to change policy on 2.7 says that (commercial vendors need it aspects aside) this is just another cycle of that same debate. Paul [1] I seem to be picking on Red Hat here. I'm not - it's just that the RHEL support cycle is the most-often quoted example of commercial support for Python 2.x, so I'm using that as my example. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 at 04:32:17, Terry Reedy (tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote: Instead, I think the PEP should propose a special series of server enhancement releases that are based on the final 2.7 maintenance release (2.7.8 or 2.7.9) but which have have a different application-specific enhancement policy. This is an interesting idea. My biggest problem with it is that, at least with the ssl library, these aren’t server-only problems. If we suggest that they are, we end up in the same position we’re in right now (that is, hurting the internet). For example, Python 2.7’s ssl module lacks the OP_NO_COMPRESSION option for OpenSSL, meaning that the application is at the mercy of the server to determine whether it’s vulnerable to the CRIME attack. Given that all modern browsers already disable TLS compression, we can assume that lots of server admins haven’t bothered disabling it on their end. This leaves pretty much anyone using HTTPS, client or server, on Python 2.7 at risk of the CRIME attack. This isn’t a server-only problem, so I feel like limiting the fixes to a ‘server’ release is not good enough. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sun, 23 Mar 2014 07:29:07 + Cory Benfield c...@lukasa.co.uk wrote: On 23 March 2014 at 04:32:17, Terry Reedy (tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote: Instead, I think the PEP should propose a special series of server enhancement releases that are based on the final 2.7 maintenance release (2.7.8 or 2.7.9) but which have have a different application-specific enhancement policy. This is an interesting idea. My biggest problem with it is that, at least with the ssl library, these aren’t server-only problems. If we suggest that they are, we end up in the same position we’re in right now (that is, hurting the internet). For example, Python 2.7’s ssl module lacks the OP_NO_COMPRESSION option for OpenSSL, This is easy to change in a bugfix release, though. Someone just has to open an issue and write a patch. 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 23, 2014, at 11:34 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 23 Mar 2014 07:29:07 + Cory Benfield c...@lukasa.co.uk wrote: On 23 March 2014 at 04:32:17, Terry Reedy (tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote: Instead, I think the PEP should propose a special series of server enhancement releases that are based on the final 2.7 maintenance release (2.7.8 or 2.7.9) but which have have a different application-specific enhancement policy. This is an interesting idea. My biggest problem with it is that, at least with the ssl library, these aren’t server-only problems. If we suggest that they are, we end up in the same position we’re in right now (that is, hurting the internet). For example, Python 2.7’s ssl module lacks the OP_NO_COMPRESSION option for OpenSSL, This is easy to change in a bugfix release, though. Someone just has to open an issue and write a patch. 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/donald%40stufft.io I already did open an issue and write a patch :) There’s someone on that issue saying that flipping that without a way to flip it back would break their application. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 3/23/2014 11:37 AM, Donald Stufft wrote: On Mar 23, 2014, at 11:34 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 23 Mar 2014 07:29:07 + Cory Benfield c...@lukasa.co.uk wrote: This is an interesting idea. My biggest problem with it is that, at least with the ssl library, these aren’t server-only problems. If we suggest that they are, we end up in the same position we’re in right now (that is, hurting the internet). For example, Python 2.7’s ssl module lacks the OP_NO_COMPRESSION option for OpenSSL, This is easy to change in a bugfix release, though. Someone just has to open an issue and write a patch. I already did open an issue and write a patch :) There’s someone on that issue saying that flipping that without a way to flip it back would break their application. http://bugs.python.org/issue20994, if anyone is looking for it. Eric. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 23, 2014, at 01:01 AM, Antoine Pitrou wrote: But enforcing secure by default can by construction break backwards compatibility, which is the very reason we are so conservative with such changes. Also, many developers who are stuck on Python 2 have already evaluated, designed, and implemented workarounds for security issues in ancient stdlib code. You have to be very careful that any changes in some future 2.7 stdlib secure-by-default release doesn't break those workarounds. That's a trick question too because you can't know all of them. I didn't read the PEP until just now, so I never saw the first draft. As written it still makes me uncomfortable because as Antoine says, lots of changes could be classified as security related and we definitely don't want this PEP to be used as a wedge to make a wink-wink-nudge-nudge release of Python 2.8. I think the key point for consumers of Python has to be *predictability*. -Barry ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 3/23/2014 3:29 AM, Cory Benfield wrote: On 23 March 2014 at 04:32:17, Terry Reedy (tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote: Instead, I think the PEP should propose a special series of server enhancement releases that are based on the final 2.7 maintenance release (2.7.8 or 2.7.9) but which have have a different application-specific enhancement policy. This is an interesting idea. My biggest problem with it is that, at least with the ssl library, these aren’t server-only problems. If we suggest that they are, we end up in the same position we’re in right now (that is, hurting the internet). If I understood the problem and pep too narrowly, substitute 'security' or whatever phrase you want for 'server'. My last sentence was an admission that some details of what I said would need to be changed. The key idea is to admit the what is being proposed is a minor fork of 2.7 (somewhat like Stackless 2.7) that might break code and which would require separate code testing -- Terry Jan Reedy ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 24 Mar 2014 09:27, Barry Warsaw ba...@python.org wrote: On Mar 23, 2014, at 01:01 AM, Antoine Pitrou wrote: But enforcing secure by default can by construction break backwards compatibility, which is the very reason we are so conservative with such changes. Also, many developers who are stuck on Python 2 have already evaluated, designed, and implemented workarounds for security issues in ancient stdlib code. You have to be very careful that any changes in some future 2.7 stdlib secure-by-default release doesn't break those workarounds. That's a trick question too because you can't know all of them. I didn't read the PEP until just now, so I never saw the first draft. As written it still makes me uncomfortable because as Antoine says, lots of changes could be classified as security related and we definitely don't want this PEP to be used as a wedge to make a wink-wink-nudge-nudge release of Python 2.8. Hence why the proposal mostly *isn't* scoped by security related. It is scoped by affects the security design of other systems, including systems not written in Python. The core problem to be solved is ensuring that the cold, dead hand of the Python 2 standard library doesn't hold back the evolution of internet security standards. I'm starting to think it makes sense to drop the higher level abstractions from the proposal, though. Once the core SSL support issue is addressed, it's comparatively straightforward to handle any other cases as PyPI modules if needed. pip, for example, already bundles requests to handle HTTPS, but that still relies on the stdlib SSL support. I think the key point for consumers of Python has to be *predictability*. Agreed. That's a key part of why the proposal is mainly about syncing certain key modules with their Python 3 counterparts, rather than piecemeal backports. That way, all you need to know is the SSL, hashlib and hmac modules are kept in sync with Python 3 feature releases, but use the same default settings as the original Python 2.7 release. A partial backport is actually *harder* for users to deal with (another reason I'm quite amenable to dropping that part of the proposal). Cheers, Nick. -Barry ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 3/23/2014 9:00 AM, Skip Montanaro wrote: On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy tjre...@udel.edu wrote: The download page for the final 2.7.z maintenance release could say something like We recommend that you move to the most recent Python 3 version if at all possible. If you cannot do that and you want to use Python to run a server on the public internet, we urge you to instead use the latest version of ServerPython 2.7.1s. This series is based on Python 2.7.z but has been and will continue to be enhanced with security features backported from Python 3. I'm unclear how this would be better than just biting the bullet and making a 2.8 release. The first step is to 'bite the bullet' and admit that the proposal is for a fork of 2.7. (Martin use that word today and pointed out the analogy with Stackless Python.) I decided not to suggest '2.8' because a) we said there would be no 2.8 (though that could be reversed); b) once we say '2.8', there would be a mountain of proposals to change this and that; c) people will expect the change from 2.7 to 2.8 to be something like previous deltas, but it will not be; d) the security fork might have a change that would normally require a deprecation period, but there might not be; and e) once a 2.8 were released, it too would be closed to enhancements, so that 2.9, 2.10, 2.11.. would eventually be needed. I mentioned this as one possible solution, but one I do not like. In summary, 2.8 is to 2.7 as 2.7 is to 2.6, etcetera would not be true, so lets not pretend or mislead people that is would be. The fork series, not being a regular CPython series, would not be subject to the regular CPython rule of needing a new minor version number for each set of enhancements and spacing the sets 18 to 24 months apart. On the one hand, the 2.7.x number suggests (based on the existing release protocol) that it should be a drop-in replacement for earlier 2.7 micro releases. No CPython x.y.z has a two-digit number for z. I know that this is a subtle hint, which is why I also propose a new name. I do not think that anyone expects Stackless Python 2.7 to be an exact drop-in replacement for any 2.7.z, although it is for code that is not affected by its specialized alterations. On the other hand, calling it something like ServerPython implies that it's not necessary for network client applications, when, if I read the PEP correctly, it most certainly would be. Consider 'ServerPython' a placeholder for a better name. In my penultimate sentence There are still details to be filled in or altered, I was specifically thinking of this. If you create a 2.8 release which is restricted to just the topic areas of the PEP (that is, no other stuff backported from 3.x, no requirement to add other non-security bug fixes, etc), the incremented minor version number tells people that a bit of extra care is required to upgrade. The lack of change in the code base outside the security apparatus should make update pretty trivial for most every non-networked application. If the PEP or something like it is approved, the work is still going to have to be done, no matter what you call it. Why not be transparent about it? We agree on being transparent, even if we have different ideas on exactly what needs to be made clear. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote: I'm unclear how this would be better than just biting the bullet and making a 2.8 release. On the one hand, the 2.7.x number suggests (based on the existing release protocol) that it should be a drop-in replacement for earlier 2.7 micro releases. On the other hand, calling it something like ServerPython implies that it's not necessary for network client applications, when, if I read the PEP correctly, it most certainly would be. It seems to me that the problem the PEP addresses can largely be confined to the Python 2.7 standard library and the fact that it's bundled with the language. I want to stick to our no-Python-2.8 pledge, but I wonder if there isn't a middle ground where we fork the stdlib into a separate branch, and apply security specific changes there. Python 2.7.x will always be the standard stdlib. We would never release a specific Python 2.7 + security stdlib release, but downstream developers would be able to overlay this forked stdlib on top of the standard one. Volunteers or corporate sponsors could distribute binary installers with this combination of pure Python 2.7 language + security enhanced stdlib, and Linux distros could do the necessary building and distributing for their own platforms if they so desired. The trick is what do you call this new combination, how do you invoke it, and how do you keep it distinct and independent of the system's standard Python 2.7? Maybe this is some scent of Python 2.8 by another name, but let's never call it Python 2.8. -Barry ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 23, 2014, at 7:03 PM, Barry Warsaw ba...@python.org wrote: On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote: I'm unclear how this would be better than just biting the bullet and making a 2.8 release. On the one hand, the 2.7.x number suggests (based on the existing release protocol) that it should be a drop-in replacement for earlier 2.7 micro releases. On the other hand, calling it something like ServerPython implies that it's not necessary for network client applications, when, if I read the PEP correctly, it most certainly would be. It seems to me that the problem the PEP addresses can largely be confined to the Python 2.7 standard library and the fact that it's bundled with the language. I want to stick to our no-Python-2.8 pledge, but I wonder if there isn't a middle ground where we fork the stdlib into a separate branch, and apply security specific changes there. Python 2.7.x will always be the standard stdlib. We would never release a specific Python 2.7 + security stdlib release, but downstream developers would be able to overlay this forked stdlib on top of the standard one. Volunteers or corporate sponsors could distribute binary installers with this combination of pure Python 2.7 language + security enhanced stdlib, and Linux distros could do the necessary building and distributing for their own platforms if they so desired. The trick is what do you call this new combination, how do you invoke it, and how do you keep it distinct and independent of the system's standard Python 2.7? Maybe this is some scent of Python 2.8 by another name, but let's never call it Python 2.8. It seems like this and the fork idea are both jumping through hoops to avoid the inevitable - a 2.7 security release or a 2.8 security only release. Especially as I know nick isn't the only one looking to hire FTEs for this specific work as it's actively hurting service providers/distributions and others. If we call it a security only release, and scope/review all patches to that it seems that it's pretty clear what the release is for. 2.x is going to be in the wild for at least another decade as these large legacy codebases are functioning, profitable and dedicating teams of engineers to port them to 3.x doesn't make sense to the business. As new services and things come online we'll see the gradual movement to 3 accelerate especially as people realize clients and service talk better on an interface such as http rather than large monolithic tragedies. -Barry ___ 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/jnoller%40gmail.com ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mon, Mar 24, 2014 at 11:03 AM, Barry Warsaw ba...@python.org wrote: Python 2.7.x will always be the standard stdlib. We would never release a specific Python 2.7 + security stdlib release, but downstream developers would be able to overlay this forked stdlib on top of the standard one. Volunteers or corporate sponsors could distribute binary installers with this combination of pure Python 2.7 language + security enhanced stdlib, and Linux distros could do the necessary building and distributing for their own platforms if they so desired. The trick is what do you call this new combination, how do you invoke it, and how do you keep it distinct and independent of the system's standard Python 2.7? Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the standard lib. Then you can go back to the standard 2.7 (if you want to) by unsetting PYTHONPATH. It'd be nice if SEPython defined a modified sys.version for clarity, but otherwise, it'd be a vanilla Python 2.7. ChrisA [1] By analogy with SELinux ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 3/23/2014 8:03 PM, Barry Warsaw wrote: On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote: I'm unclear how this would be better than just biting the bullet and making a 2.8 release. On the one hand, the 2.7.x number suggests (based on the existing release protocol) that it should be a drop-in replacement for earlier 2.7 micro releases. On the other hand, calling it something like ServerPython implies that it's not necessary for network client applications, when, if I read the PEP correctly, it most certainly would be. It seems to me that the problem the PEP addresses can largely be confined to the Python 2.7 standard library and the fact that it's bundled with the language. I want to stick to our no-Python-2.8 pledge, but I wonder if there isn't a middle ground where we fork the stdlib into a separate branch, and apply security specific changes there. Python 2.7.x will always be the standard stdlib. We would never release a specific Python 2.7 + security stdlib release, but downstream developers would be able to overlay this forked stdlib on top of the standard one. Volunteers or corporate sponsors could distribute binary installers with this combination of pure Python 2.7 language + security enhanced stdlib, and Linux distros could do the necessary building and distributing for their own platforms if they so desired. The trick is what do you call this new combination, I have already agree that 'ServerPython' is just a placeholder. how do you invoke it, and how do you keep it distinct and independent of the system's standard Python 2.7? Maybe this is some scent of Python 2.8 by another name, but let's never call it Python 2.8. I agree, no only because of the 'pledge', but because it is the wrong model. Nick's latest paraphrase of where he thinks his proposal is heading is the SSL, hashlib and hmac modules are kept in sync with Python 3 feature releases, but use the same default settings as the original Python 2.7 release. '2.8' would imply a broader focus than just 3 modules, and it would only work for the first of a series of enhancement releases. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 3/23/2014 7:48 PM, Nick Coghlan wrote: Agreed. That's a key part of why the proposal is mainly about syncing certain key modules with their Python 3 counterparts, rather than piecemeal backports. That way, all you need to know is the SSL, hashlib and hmac modules are kept in sync with Python 3 feature releases, but use the same default settings as the original Python 2.7 release. If you restrict the proposal to just those three modules, then the proposal could be to just add three new modules to 2.7: ssl3, hashlib3, and hmac3. Each would be regularly updated backports of the 3.x modules with two differences: defaults for settings that exist in 2.7 would remain as in 2.7 and would not be updated*, and each module would get a .py3_ver x.y.z attribute so code could be conditioned on which backport version it is running with. * though users would be encouraged to use the most secure settings. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 23, 2014, at 8:31 PM, Jesse Noller jnol...@gmail.com wrote: On Mar 23, 2014, at 7:03 PM, Barry Warsaw ba...@python.org wrote: On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote: I'm unclear how this would be better than just biting the bullet and making a 2.8 release. On the one hand, the 2.7.x number suggests (based on the existing release protocol) that it should be a drop-in replacement for earlier 2.7 micro releases. On the other hand, calling it something like ServerPython implies that it's not necessary for network client applications, when, if I read the PEP correctly, it most certainly would be. It seems to me that the problem the PEP addresses can largely be confined to the Python 2.7 standard library and the fact that it's bundled with the language. I want to stick to our no-Python-2.8 pledge, but I wonder if there isn't a middle ground where we fork the stdlib into a separate branch, and apply security specific changes there. Python 2.7.x will always be the standard stdlib. We would never release a specific Python 2.7 + security stdlib release, but downstream developers would be able to overlay this forked stdlib on top of the standard one. Volunteers or corporate sponsors could distribute binary installers with this combination of pure Python 2.7 language + security enhanced stdlib, and Linux distros could do the necessary building and distributing for their own platforms if they so desired. The trick is what do you call this new combination, how do you invoke it, and how do you keep it distinct and independent of the system's standard Python 2.7? Maybe this is some scent of Python 2.8 by another name, but let's never call it Python 2.8. It seems like this and the fork idea are both jumping through hoops to avoid the inevitable - a 2.7 security release or a 2.8 security only release. Especially as I know nick isn't the only one looking to hire FTEs for this specific work as it's actively hurting service providers/distributions and others. If we call it a security only release, and scope/review all patches to that it seems that it's pretty clear what the release is for. 2.x is going to be in the wild for at least another decade as these large legacy codebases are functioning, profitable and dedicating teams of engineers to port them to 3.x doesn't make sense to the business. As new services and things come online we'll see the gradual movement to 3 accelerate especially as people realize clients and service talk better on an interface such as http rather than large monolithic tragedies. -Barry ___ 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/jnoller%40gmail.com ___ 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/donald%40stufft.io I agree, the bulk of the alternative suggestions feel more like trying to adhere to a policy for policy’s sake rather than actually figure out what is best for the users. Adding new APIs to 2.7 feels to me like a pretty backwards compatible thing to be honest. The biggest contenders are things like SSLContext and match_hostname. The PEP still says things must be backwards compatible so we can't change existing APIs in a way that the backported things aren't opt in. I mean how likely is it that there is code out there relying on the fact that SSLContext doesn't exist other than as a detection to determine if they can use SSLContext? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 24, 2014, at 11:38 AM, Chris Angelico wrote: Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the standard lib. Then you can go back to the standard 2.7 (if you want to) by unsetting PYTHONPATH. It'd be nice if SEPython defined a modified sys.version for clarity, but otherwise, it'd be a vanilla Python 2.7. That's certainly more in the direction of what I think is an appropriate upstream solution. The thing is, there isn't one single what's best for users resolution. There are many, many competing requirements and I think it will be difficult to satisfy everyone. I'm particularly sensitive to complaints of unexpected changes between micro releases. -Barry ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 23, 2014, at 9:31 PM, Barry Warsaw ba...@python.org wrote: On Mar 24, 2014, at 11:38 AM, Chris Angelico wrote: Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the standard lib. Then you can go back to the standard 2.7 (if you want to) by unsetting PYTHONPATH. It'd be nice if SEPython defined a modified sys.version for clarity, but otherwise, it'd be a vanilla Python 2.7. That's certainly more in the direction of what I think is an appropriate upstream solution. The thing is, there isn't one single what's best for users resolution. There are many, many competing requirements and I think it will be difficult to satisfy everyone. I'm particularly sensitive to complaints of unexpected changes between micro releases. If it’s too much for a micro release call it 2.8 or 2.9 or something and give it a super limited scope. Proposals like modifying the sys.path to opt into the backported things or having an official unofficial stdlib just adds more things downstream users have to actually test against and more possible configurations or Pythons. Right now users have a singular method for determining what the runtime environment looks like for Python, the version. There are processes around selecting different Python versions for things, upgrading etc. This isn’t a new thing for users. Suddenly having to mess with PYTHONPATH or having to figure out if their distro used the “official stdlib” or the “official unofficial stdlib” just adds massive confusion. Things like ssl3 etc are “ok” but less than optimal IMO because one of the benefits of adding SSLContext and such to Python 2.x is that you can write code that works in 2.x and 3.x without having to special case 2.7.7 or 2.8 or whatever. However if you just add ssl3 then now you have a third path through the code that you have to deal with. -Barry ___ 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/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mon, Mar 24, 2014 at 1:34 PM, Donald Stufft don...@stufft.io wrote: Right now users have a singular method for determining what the runtime environment looks like for Python, the version. There are processes around selecting different Python versions for things, upgrading etc. This isn’t a new thing for users. Suddenly having to mess with PYTHONPATH or having to figure out if their distro used the “official stdlib” or the “official unofficial stdlib” just adds massive confusion. Various distros of Linux ship modified versions of things. On my current system (Debian Wheezy), the apt-gettable Python is tagged 2.7.3-4+deb7u1, so there are already at least some patches that aren't in vanilla 2.7.3. Presumably the distro could happily just ship the enhanced stdlib, and you don't need to mess with PYTHONPATH; and a modified sys.version or other detection method could be used to probe if you need to be sure. As has already been pointed out, this can already happen, but in an ad-hoc way. Making it official or semi-official would mean that a script written for Debian's Python 2.7.10 would run on Red Hat's Python 2.7.10, which would surely be an advantage. ChrisA ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Thanks for putting this together Nick. I suspect it goes without saying that I'm wildly +1 on this as a whole. I'm in favor of leaving it somewhat implicit as to exactly which networking modules concern the health of the internet as a whole. Alex ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat, Mar 22, 2014, at 14:11, Nick Coghlan wrote: Folks, I have just posted a proposal to change the way we treat enhancements that relate to Python's support for network security enhancements. I think the PEP should also address security-mode releases. Do the same exceptions apply? Does anyone really want to backport features to Python 3.1? ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 22 March 2014 at 21:11:24, Nick Coghlan (ncogh...@gmail.com(mailto:ncogh...@gmail.com)) wrote: Folks, I have just posted a proposal to change the way we treat enhancements that relate to Python's support for network security enhancements. I now see these as categorically different from most other enhancements, as they have implications for the evolution of internet security as a whole, rather than being limited to affecting the security of individual applications written in Python. I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7 is a security liability, any it becomes nothing short of irresponsible to use Python 2.7 for any form of networking code that hits the open internet. On top of that, the current state of the ssl module means that Python 2.7 and earlier cannot ever support a standard-compliant implementation of things like HTTP/2. That’s a fairly tragic state of affairs for 2.7, especially if we’re supposed to claim with a straight face that it’s acceptable to still use Python 2.7. Treat this as my strong +1. Additionally, I’m happy to volunteer my time and limited expertise to help make this happen. I’ll help work on back porting things, review code, write docs: whatever it takes to get this to happen. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/22/2014 05:11 PM, Nick Coghlan wrote: In addition to any other module specific contents, this section MUST enumerate key security enhancements and fixes (with CVE identifiers where applicable), and the Incomplete sentence. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMuBosACgkQ+gerLs4ltQ74ngCfS7MLZHtVfS7f6x+9mnOIsp+c +CUAoIc5rFIuNJvMephnlAuPhkPXZspy =N8Xk -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
I think the pep doesn't mandate that someone does. It still requires someone to care enough to actually write the patch. It just allows such a patch to be merged. On Mar 22, 2014, at 5:32 PM, Benjamin Peterson benja...@python.org wrote: Does anyone really want to backport features to Python 3.1? ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 22.03.14 22:17, schrieb Cory Benfield: I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7 is a security liability, any it becomes nothing short of irresponsible to use Python 2.7 for any form of networking code that hits the open internet. Agreed (although this might be a slight overstatement if taken literally). However, the right consequence should be to use Python 3.4 instead. Regards, Martin ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Just use Python 3.4 ignores the reality of production software. I wish it were that simple because I love 3.4 On Mar 22, 2014, at 6:16 PM, Martin v. Löwis mar...@v.loewis.de wrote: Am 22.03.14 22:17, schrieb Cory Benfield: I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7 is a security liability, any it becomes nothing short of irresponsible to use Python 2.7 for any form of networking code that hits the open internet. Agreed (although this might be a slight overstatement if taken literally). However, the right consequence should be to use Python 3.4 instead. Regards, Martin ___ 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/donald%40stufft.io ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 22.03.14 22:11, schrieb Nick Coghlan: Title: Network Security Enhancement Exception for All Branches I'm -0 on the general idea, and -1 on the inclusion of the 2.7 branch into the policy. The PEP trades security concerns against stability and maintainability. I see a maintenance threat coming out of it: existing installations will fail to operate after updating Python and some support libraries. Bug fix releases ought to focus on maintenance much more than moving along with general security threats. Software that ages needs to be retired, instead of trying to fix it endlessly (which is a futile exerciese, anyway). Everybody knows it, and has accepted it, so why should we fight what seems to be a fundamental law of software evolution? In the specific case of 2.7, I am hoping that we retire the branch soon. If so, it would be counter-productive to backport the current features to 2.7. They are still in progress, and users wouldn't be helped with getting a new feature in just the final bug fix release of 2.7, with no chance of then getting updates of the same feature, as there won't be any further bugfix releases. Finally, doing this in the 2.7 branch likely involves more effort than I'm personally willing to provide. Regards, Martin ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 22.03.14 23:05, schrieb Donald Stufft: I think the pep doesn't mandate that someone does. It still requires someone to care enough to actually write the patch. It just allows such a patch to be merged. Does it actually? Unfortunately, I never got around to writing the PEP on security-only branches, so the terminology of PEP 466 is unclear. It says maintenance brances, which could mean three things: - all branches that have ever been made off default in hg.python.org/cpython (i.e. back to 2.0). This would be the traditional definition of maintenance branch in a version control system, but is probably not intended by the PEP - all branches from which still releases are made (whether security-only or bug fix) - all bug fix branches Clarification of this is just a minor nit, though - although the maintainers of the old maintenance branches should (IMO) have a say whether they accept a certain change on a certain branch. Regards, Martin ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 08:14, Martin v. Löwis mar...@v.loewis.de wrote: Am 22.03.14 22:11, schrieb Nick Coghlan: Finally, doing this in the 2.7 branch likely involves more effort than I'm personally willing to provide. Believe me, I'll be escalating these concerns at work this week. We have to shoulder a lot of the responsibility for creating this problem in the first place, so I think it's fair for people to expect us to help fix it. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 22.03.14 23:21, schrieb Donald Stufft: Just use Python 3.4 ignores the reality of production software. I wish it were that simple because I love 3.4 But I think so does the PEP (i.e. ignore the reality of production software). The risk of breaking existing installations (which might not be affected by the purported security threat being fixed) is just too high. Users that feel threatened by the lack of SSL features in Python should have long started planning on how to get to Python 3. It's not that they haven't been warned. Regards, Martin ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 08:23, Martin v. Löwis mar...@v.loewis.de wrote: Am 22.03.14 23:05, schrieb Donald Stufft: I think the pep doesn't mandate that someone does. It still requires someone to care enough to actually write the patch. It just allows such a patch to be merged. Does it actually? Unfortunately, I never got around to writing the PEP on security-only branches, so the terminology of PEP 466 is unclear. It says maintenance brances, which could mean three things: - all branches that have ever been made off default in hg.python.org/cpython (i.e. back to 2.0). This would be the traditional definition of maintenance branch in a version control system, but is probably not intended by the PEP - all branches from which still releases are made (whether security-only or bug fix) - all bug fix branches Clarification of this is just a minor nit, though - although the maintainers of the old maintenance branches should (IMO) have a say whether they accept a certain change on a certain branch. Both good points, I'll clarify them in the PEP. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
In article cadisq7czsp1flv31izz01_9avgyzsc1j6+d2t5aup2byu97...@mail.gmail.com, Nick Coghlan ncogh...@gmail.com wrote: I have just posted a proposal to change the way we treat enhancements that relate to Python's support for network security enhancements. +1 [...] Open Questions == * What are the risks associated with allowing OpenSSL to be updated to new feature versions in the Windows and Mac OS X binary installers for maintenance releases? Regarding the python.org binary installers, I think past practice has been for us to update third-party libraries as necessary in maintenance releases when there is good cause and with the concurrence of the release manager, so I don't see this as a big issue. For the OS X binary installer, the issue for OpenSSL has been that we dynamically link to the system-supplied OpenSSL libraries and that, for various reasons, Apple has deprecated (and frozen at non-current OpenSSL releases) the use of those libraries in favor of their own security frameworks. So, for multiple reasons, including the risk that OpenSSL may be dropped from an upcoming major release of OS X, we need to start supplying our own version with all OS X binary installers. That's the plan regardless of the outcome of this PEP. -- Ned Deily, n...@acm.org ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 08:16, Martin v. Löwis mar...@v.loewis.de wrote: Am 22.03.14 22:17, schrieb Cory Benfield: I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7 is a security liability, any it becomes nothing short of irresponsible to use Python 2.7 for any form of networking code that hits the open internet. Agreed (although this might be a slight overstatement if taken literally). However, the right consequence should be to use Python 3.4 instead. The PEP does try to address this point in the Motivation Rationale sections: = Requiring that latent defects in an application's Unicode correctness be addressed in order to migrate to Python 3 is not a reasonable alternative recommendation, especially given the likely existence of legacy code that lacks the kind of automated regression test suite needed to help support a migration from Python 2 to Python 3. The key point of this PEP is that those situations affect more people than just the developers and users of the affected application: their existence becomes something that developers of secure networked services need to take into account as part of their security design. By making it more feasible to enhance the security of the Python 2 series, we can help contribute to the evolution of a more secure internet for all concerned. = Hard to maintain legacy software is a fact of life, and way too much of it is exposed to the public internet. This PEP is about doing what we can to mitigate the damage caused both by other people's mistakes, and also the inherent challenges of migrating from the error prone POSIX text model to something more reasonable. I *don't* think its reasonable to expect us to do this without support from the corporate users that caused the problem in the first place (by continuing to deploy older versions of Python without investing adequately in their upkeep), so I'd encourage everyone employed by a commercial user of Python to remind their management chains of the risks of failing to invest development time in any upstream dependencies that they expect to keep pace with the dynamic nature of the internet. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 22.03.14 23:33, schrieb Nick Coghlan: Hard to maintain legacy software is a fact of life, and way too much of it is exposed to the public internet. This PEP is about doing what we can to mitigate the damage caused both by other people's mistakes, and also the inherent challenges of migrating from the error prone POSIX text model to something more reasonable. I *don't* think its reasonable to expect us to do this without support from the corporate users that caused the problem in the first place (by continuing to deploy older versions of Python without investing adequately in their upkeep), so I'd encourage everyone employed by a commercial user of Python to remind their management chains of the risks of failing to invest development time in any upstream dependencies that they expect to keep pace with the dynamic nature of the internet. I hope indeed you are successful in activating resources. However, putting them on this backporting project seems like a waste. They should rather go into porting stuff to 3.x where people need it. As responsible maintainers, we should just advise our users that Python 2.7 is a dead horse, and that they should stop riding it. More professionally, we should set an official end-of-life date for 2.7 (alas, we should have done that two years ago). I hope that the language summit can agree to stopping bug fix releases for 2.7 in 2014. Regards, Martin ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 22.03.2014 22:11, Nick Coghlan wrote: PEP: 466 Title: Network Security Enhancement Exception for All Branches +1 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 22 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-03-29: PythonCamp 2014, Cologne, Germany ... 7 days to go 2014-04-09: PyCon 2014, Montreal, Canada ... 18 days to go 2014-04-29: Python Meeting Duesseldorf ... 38 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 08:40, Martin v. Löwis mar...@v.loewis.de wrote: Am 22.03.14 23:33, schrieb Nick Coghlan: Hard to maintain legacy software is a fact of life, and way too much of it is exposed to the public internet. This PEP is about doing what we can to mitigate the damage caused both by other people's mistakes, and also the inherent challenges of migrating from the error prone POSIX text model to something more reasonable. I *don't* think its reasonable to expect us to do this without support from the corporate users that caused the problem in the first place (by continuing to deploy older versions of Python without investing adequately in their upkeep), so I'd encourage everyone employed by a commercial user of Python to remind their management chains of the risks of failing to invest development time in any upstream dependencies that they expect to keep pace with the dynamic nature of the internet. I hope indeed you are successful in activating resources. However, putting them on this backporting project seems like a waste. They should rather go into porting stuff to 3.x where people need it. Red Hat will be supporting Python 2.6 until 2020'ish, Python 2.7 until at least 2024 (since RHEL7 isn't actually out yet). Python 2 is part of one of our core products (RHEL), and a dependency of another one (OpenStack). While the wheels are in motion upstream to migrate both to Python 3, that's a long term project in both cases, and really hard to make a business case for. While we do believe the open source way delivers better software in the long run, we still have to make our case when we want the company to spend time and resources on something. As responsible maintainers, we should just advise our users that Python 2.7 is a dead horse, and that they should stop riding it. More professionally, we should set an official end-of-life date for 2.7 (alas, we should have done that two years ago). This completely ignores the practical realities of commercial software development, and the commitments that vendors have made to their customers. I agree it would be completely unreasonable to ask volunteers to contribute their own time to making this proposal work. However, it's likely to be much easier for those of us with influence in the commercial world to shake some resources loose if we have a pre-arranged agreement on the specific help we need to better support their interests. I hope that the language summit can agree to stopping bug fix releases for 2.7 in 2014. I'd rather come up with a plan to seek dedicated resources from key corporate users to help with the boring parts of long term maintenance that are really hard to get volunteers excited about, but make a great avenue for corporate sponsored contributions without infringing on the upstream community's autonomy. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
I agree wholeheartedly with the sentiment behind this PEP, but I have concerns about the implementation. If we introduce new APIs into the ssl module then we will see packages and applications that depend on Python 2.7.7+, just like with the introduction of bool in 2.2.1. This will be a mess unless adoption of new Python minor versions is swift and consistent. The PEP says that new features should be testable with feature detection, but how far does that go? The Python 3 NPN interface is a method of SSLContext, which didn't exist in 2.7. Do we backport the entire SSLContext interface in a minor release, or introduce a new NPN interface that is not based on SSLContext just for older Pythons? In my experience most deployments of Python apps have better systems in place to deal with packages installed from PyPI than new versions of Python itself. Therefore it might be better to follow the lead of the unittest2 module and introduce a new ssl2 module that tracks the most recent version of Python's ssl module. My counter-proposal is: * Introduce a new module 'ssl2' which is essentially a backport of the current release's ssl module for all old versions of Python that anyone cares to support. * Third-party applications and libraries targeting anything but the latest version of Python are advised to use ssl2 instead of ssl (this might also be a good opportunity to bless certifi or an equivalent). * Minor releases of Python are allowed to make any security-related change that does not change any public interfaces (e.g. linking against a new version of openssl, or disabling SSLv2) * New interfaces in security-related modules are allowed only if those new interfaces are used by other stdlib modules (since stdlib modules are the only place where ssl2 is off-limits). For example, a backport of match_hostname could go in if httplib or urllib used it. NPN/ALPN would not be allowed under this rule since there is no stdlib code that uses them; third-party SPDY or HTTP/2 code would have to use ssl2 to get this interface. In this world, libraries like requests or tornado that want to use advanced ssl features can simply declare a dependency on ssl2, instead of saying we require Python 2.7.7+, 3.2.6+, etc. In spite of my reservations about this PEP, I'd still love to see SSL improvements in 2.7 in any form. I'm currently planning a port for Tornado's ssl usage from the stdlib ssl module to PyOpenSSL (in order to get SNI and NPN/ALPN features), and I'd really rather not have to convert to a completely incompatible interface. -Ben On Sat, Mar 22, 2014 at 5:11 PM, Nick Coghlan ncogh...@gmail.com wrote: Folks, I have just posted a proposal to change the way we treat enhancements that relate to Python's support for network security enhancements. I now see these as categorically different from most other enhancements, as they have implications for the evolution of internet security as a whole, rather than being limited to affecting the security of individual applications written in Python. 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. This new PEP proposes a similar exception for network security related changes, such that the *capabilities* of all still maintained versions should be kept equivalent, with only the *default settings* varying across up to date feature releases. The policy is also designed to make it easier for us to ratchet up the default security settings in future feature releases. However, it's more complex than the IDLE PEP (since it's more invasive), and there are still a few open questions listed. 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. Full PEP included inline below, and available in more readable form at http://www.python.org/dev/peps/pep-0466/ Regards, Nick. PEP: 466 Title: Network Security Enhancement Exception for All Branches Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan ncogh...@gmail.com, Status: Draft Type: Informational Content-Type: text/x-rst Created: 23-Mar-2014 Post-History: 23-Mar-2014 Abstract Most CPython tracker issues are classified as errors in behaviour or proposed enhancements. Most patches to fix behavioural errors are applied to all active maintenance branches. Enhancement patches are restricted to the default branch that becomes the next Python version. This PEP relaxes the latter restriction allowing enhancements to be applied to maintenance
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat, Mar 22, 2014 at 11:26 PM, Martin v. Löwis mar...@v.loewis.dewrote: Am 22.03.14 23:21, schrieb Donald Stufft: Just use Python 3.4 ignores the reality of production software. I wish it were that simple because I love 3.4 But I think so does the PEP (i.e. ignore the reality of production software). The risk of breaking existing installations (which might not be affected by the purported security threat being fixed) is just too high. Users that feel threatened by the lack of SSL features in Python should have long started planning on how to get to Python 3. It's not that they haven't been warned. Or not rely on the standard library for their security. Much as I realize it is necessary for rudimentary SSL support (for example) to exist in the standard library, any security-aware user is much better served by third-party packages they can update more easily than Python. I really wish we had no SSL *server* support in the standard library at all (but then I wish we didn't have so many middling-quality servers in the stdlib to start with :) Even when we're not considering virtualenvs, which are a great tool for preventing upgrades from breaking things, separately-installed packages (be they third-party or official python.org packages) are much easier to upgrade than whole Python installations. And a third-party package like PyOpenSSL has much more freedom in dealing with backward-incompatible changes (because users updating PyOpenSSL are much more likely to realize something regarding SSL could break, even if they aren't more likely to read the release documentation.) I think I'm +0 on the PEP: I understand Martin's concerns, and share them (heck, I'm preparing for an update from Python 2.7.3 to 2.7.6 at work and I'm already having nightmares) but I also understand the problem the PEP tries to solve. I wish we would separate out e.g. the SSL-related modules so they aren't part of the 'core' Python but not quite third-party packages either, but that's not something that's easily done. I do believe that besides accepting this PEP we should provide good guidance on how to write portable, secure software using the tools provided, say in a new chapter in the library docs -- and it shouldn't be afraid to suggest third-party modules if they are a much better solution :) -- Thomas Wouters tho...@python.org Hi! I'm an email virus! Think twice before sending your email to help me spread! ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat, Mar 22, 2014, at 15:40, Martin v. Löwis wrote: Am 22.03.14 23:33, schrieb Nick Coghlan: Hard to maintain legacy software is a fact of life, and way too much of it is exposed to the public internet. This PEP is about doing what we can to mitigate the damage caused both by other people's mistakes, and also the inherent challenges of migrating from the error prone POSIX text model to something more reasonable. I *don't* think its reasonable to expect us to do this without support from the corporate users that caused the problem in the first place (by continuing to deploy older versions of Python without investing adequately in their upkeep), so I'd encourage everyone employed by a commercial user of Python to remind their management chains of the risks of failing to invest development time in any upstream dependencies that they expect to keep pace with the dynamic nature of the internet. I hope indeed you are successful in activating resources. However, putting them on this backporting project seems like a waste. They should rather go into porting stuff to 3.x where people need it. As responsible maintainers, we should just advise our users that Python 2.7 is a dead horse, and that they should stop riding it. More professionally, we should set an official end-of-life date for 2.7 (alas, we should have done that two years ago). I hope that the language summit can agree to stopping bug fix releases for 2.7 in 2014. As (I believe) previously discussed and documented in PEP 373, this date currently will be May 2015. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
As someone who is deeply biased towards improving the packaging tool chain and getting people to use it I think that most people will simply use the Stdlib even if a more secure alternative exists. Infact one does exist and I still see almost everyone using the stdlib ssl instead of pyopenssl. At best they have an optional dependency on it which many people who aren't security conscious won't even realize why they should install it. On Mar 22, 2014, at 6:53 PM, Ben Darnell b...@bendarnell.com wrote: I agree wholeheartedly with the sentiment behind this PEP, but I have concerns about the implementation. If we introduce new APIs into the ssl module then we will see packages and applications that depend on Python 2.7.7+, just like with the introduction of bool in 2.2.1. This will be a mess unless adoption of new Python minor versions is swift and consistent. The PEP says that new features should be testable with feature detection, but how far does that go? The Python 3 NPN interface is a method of SSLContext, which didn't exist in 2.7. Do we backport the entire SSLContext interface in a minor release, or introduce a new NPN interface that is not based on SSLContext just for older Pythons? In my experience most deployments of Python apps have better systems in place to deal with packages installed from PyPI than new versions of Python itself. Therefore it might be better to follow the lead of the unittest2 module and introduce a new ssl2 module that tracks the most recent version of Python's ssl module. My counter-proposal is: * Introduce a new module 'ssl2' which is essentially a backport of the current release's ssl module for all old versions of Python that anyone cares to support. * Third-party applications and libraries targeting anything but the latest version of Python are advised to use ssl2 instead of ssl (this might also be a good opportunity to bless certifi or an equivalent). * Minor releases of Python are allowed to make any security-related change that does not change any public interfaces (e.g. linking against a new version of openssl, or disabling SSLv2) * New interfaces in security-related modules are allowed only if those new interfaces are used by other stdlib modules (since stdlib modules are the only place where ssl2 is off-limits). For example, a backport of match_hostname could go in if httplib or urllib used it. NPN/ALPN would not be allowed under this rule since there is no stdlib code that uses them; third-party SPDY or HTTP/2 code would have to use ssl2 to get this interface. In this world, libraries like requests or tornado that want to use advanced ssl features can simply declare a dependency on ssl2, instead of saying we require Python 2.7.7+, 3.2.6+, etc. In spite of my reservations about this PEP, I'd still love to see SSL improvements in 2.7 in any form. I'm currently planning a port for Tornado's ssl usage from the stdlib ssl module to PyOpenSSL (in order to get SNI and NPN/ALPN features), and I'd really rather not have to convert to a completely incompatible interface. -Ben On Sat, Mar 22, 2014 at 5:11 PM, Nick Coghlan ncogh...@gmail.com wrote: Folks, I have just posted a proposal to change the way we treat enhancements that relate to Python's support for network security enhancements. I now see these as categorically different from most other enhancements, as they have implications for the evolution of internet security as a whole, rather than being limited to affecting the security of individual applications written in Python. 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. This new PEP proposes a similar exception for network security related changes, such that the *capabilities* of all still maintained versions should be kept equivalent, with only the *default settings* varying across up to date feature releases. The policy is also designed to make it easier for us to ratchet up the default security settings in future feature releases. However, it's more complex than the IDLE PEP (since it's more invasive), and there are still a few open questions listed. 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. Full PEP included inline below, and available in more readable form at http://www.python.org/dev/peps/pep-0466/ Regards, Nick. PEP: 466 Title: Network Security Enhancement Exception for All
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 08:53, Ben Darnell b...@bendarnell.com wrote: I agree wholeheartedly with the sentiment behind this PEP, but I have concerns about the implementation. If we introduce new APIs into the ssl module then we will see packages and applications that depend on Python 2.7.7+, just like with the introduction of bool in 2.2.1. This will be a mess unless adoption of new Python minor versions is swift and consistent. The PEP says that new features should be testable with feature detection, but how far does that go? The Python 3 NPN interface is a method of SSLContext, which didn't exist in 2.7. Do we backport the entire SSLContext interface in a minor release, or introduce a new NPN interface that is not based on SSLContext just for older Pythons? The whole thing. The problem at the moment is that too many applications just silently run without proper security settings on older Python release, as users don't completely want to drop support for that version, but also decide it's too hard to enable the right security settings properly. The idea here is to make it easy for them to enable the settings if they're available, but still fall back to their old behaviour if they're not. The fail or fall back decision will depend on the library and its assessment of security compatibility vs breadth of support for legacy versions. The issue isn't really the ssl module itself - it's the other modules that *depend* on the ssl module (like httplib, urllib, poplib, ftplib, imaplib). You could technically try to monkeypatch or shadow the stdlib ssl module from a third party library, but that's a *really* dangerous approach to security (since it makes it hard to do proper integration testing). In my experience most deployments of Python apps have better systems in place to deal with packages installed from PyPI than new versions of Python itself. Therefore it might be better to follow the lead of the unittest2 module and introduce a new ssl2 module that tracks the most recent version of Python's ssl module. My counter-proposal is: * Introduce a new module 'ssl2' which is essentially a backport of the current release's ssl module for all old versions of Python that anyone cares to support. It's not just ssl2: you needs os2, random2, ftplib2, poplib2, imaplib2, smtplib2. You also run headlong into the problem of a complex external dependency on OpenSSL (which the Linux distro repackagers currently handle for us). This is what the reimplementing substantial portions of the standard library as third party modules to gain access to the newer underlying network security protocols and mechanisms, and then injecting those into the module namespace to override their standard library counterparts. comment is about, but I guess I should expand on that for the benefit of readers not as familiar with the relevant implementation details. * Third-party applications and libraries targeting anything but the latest version of Python are advised to use ssl2 instead of ssl (this might also be a good opportunity to bless certifi or an equivalent). * Minor releases of Python are allowed to make any security-related change that does not change any public interfaces (e.g. linking against a new version of openssl, or disabling SSLv2) New versions of OpenSSL are nowhere near as useful when their constants aren't made available in the Python API. * New interfaces in security-related modules are allowed only if those new interfaces are used by other stdlib modules (since stdlib modules are the only place where ssl2 is off-limits). For example, a backport of match_hostname could go in if httplib or urllib used it. NPN/ALPN would not be allowed under this rule since there is no stdlib code that uses them; third-party SPDY or HTTP/2 code would have to use ssl2 to get this interface. In this world, libraries like requests or tornado that want to use advanced ssl features can simply declare a dependency on ssl2, instead of saying we require Python 2.7.7+, 3.2.6+, etc. There's a reason the developers of those libraries haven't already done that: it's genuinely hard. It's not that I didn't think of this approach, it's that I think it would actually be more difficult and less effective than the approach currently in the PEP. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 22.03.14 23:39, schrieb Ned Deily: Regarding the python.org binary installers, I think past practice has been for us to update third-party libraries as necessary in maintenance releases when there is good cause and with the concurrence of the release manager, so I don't see this as a big issue. For the OS X binary installer, the issue for OpenSSL has been that we dynamically link to the system-supplied OpenSSL libraries and that, for various reasons, Apple has deprecated (and frozen at non-current OpenSSL releases) the use of those libraries in favor of their own security frameworks. So, for multiple reasons, including the risk that OpenSSL may be dropped from an upcoming major release of OS X, we need to start supplying our own version with all OS X binary installers. That's the plan regardless of the outcome of this PEP. The Windows case is similar but different. I also update OpenSSL releases between Python bug fix releases, but only to OpenSSL bug fix releases (likewise for all other third party software). So 2.7 uses 0.9.8 (currently 0.9.8y), 3.3 and 3.4 use 1.0.1 (currently 1.0.1e). I still wish it was possible to drop OpenSSL altogether on both OSX and Windows, and use the vendor TLS libraries instead. This would reduce the maintenance burden, and might even improve performance. However, it's getting difficult since the ssl module exposes more and more OpenSSL API as-is (rather than trying to provide an abstraction). For Windows, this approach was unfortunately hopeless as long as we had to support XP. Now that Vista becomes the baseline, I hope I can try to provide much of the ssl module natively using CryptoAPI. Regards, Martin ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 23.03.14 00:02, schrieb Benjamin Peterson: As (I believe) previously discussed and documented in PEP 373, this date currently will be May 2015. Ah! Thanks for reminding me. I think PEP 466 then needs to take a position on that, as well. By the past schedule, this probably means two more bug fix releases for 2.7 (which is fine with me). However, I expect this to be a problem for the PEP, since it is unrealistic to expect that all aspects of the desired features are complete by 2015 (i.e. with no need for further updates in the coming years). Regards, Martin ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 22 March 2014 23:07, Donald Stufft don...@stufft.io wrote: As someone who is deeply biased towards improving the packaging tool chain and getting people to use it I think that most people will simply use the Stdlib even if a more secure alternative exists. Infact one does exist and I still see almost everyone using the stdlib ssl instead of pyopenssl. At best they have an optional dependency on it which many people who aren't security conscious won't even realize why they should install it. Windows users typically will not be able to use something like pyopenssl. It's a complex binary dependency with no wheel on PyPI. There are no easily locatable wininst installers, even - and those are messy to use in a virtualenv. While the stdlib modules may have issues, depend on pyopenssl is not a practical solution for many people. Paul ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 07:32, Benjamin Peterson benja...@python.org wrote: On Sat, Mar 22, 2014, at 14:11, Nick Coghlan wrote: Folks, I have just posted a proposal to change the way we treat enhancements that relate to Python's support for network security enhancements. I think the PEP should also address security-mode releases. Do the same exceptions apply? Does anyone really want to backport features to Python 3.1? As I see it, RHEL is the primary culprit for people still caring about Python 2.6. With the RHEL7 beta published late last year and hence CentOS 7 and RHEL 7 itself presumably landing well before Python 2.7 enters security fix only mode, I think it's OK to leave this aspect in the hands of the distro vendors and other commercial redistributors. We create the problem, we can bear the cost of dealing with it on behalf of our users. In Red Hat's specific case, we're also finally starting to offer users better solutions that make it easier to switch to a newer language runtime without having to upgrade the entire underlying OS or run in an unsupported configuration. In the longer term, this will hopefully mean that the expectation for upstream projects to maintain compatibility with the system Python in RHEL will become limited to just those projects that we actually include as part of the distro. However, I agree the PEP needs to have a dedicated section discussing security fix only releases. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 09:07, Donald Stufft don...@stufft.io wrote: As someone who is deeply biased towards improving the packaging tool chain and getting people to use it I think that most people will simply use the Stdlib even if a more secure alternative exists. Infact one does exist and I still see almost everyone using the stdlib ssl instead of pyopenssl. At best they have an optional dependency on it which many people who aren't security conscious won't even realize why they should install it. I should probably mention explicitly in the PEP that security related packages almost always involve somewhat tricky binary dependencies, and while we're working on it, our packaging ecosystem will still sometimes deliver a poor user experience on that front. There's also an inherent divide between using an old version of Python and willing to use new dependencies from pip. They're not disjoint sets (plenty of folks use the CentOS system Python + pip), but I expect there's a large enough population of conservative corporate users on older versions that won't use a pip based solution even if its available, thus not really solving the problem. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat, 22 Mar 2014 19:07:51 -0400 Donald Stufft don...@stufft.io wrote: As someone who is deeply biased towards improving the packaging tool chain and getting people to use it I think that most people will simply use the Stdlib even if a more secure alternative exists. Infact one does exist and I still see almost everyone using the stdlib ssl instead of pyopenssl. pyopenssl exposes a different API from ssl, though. It's not just a matter of flipping an import statement. 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sun, 23 Mar 2014 09:08:29 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 23 March 2014 08:53, Ben Darnell b...@bendarnell.com wrote: I agree wholeheartedly with the sentiment behind this PEP, but I have concerns about the implementation. If we introduce new APIs into the ssl module then we will see packages and applications that depend on Python 2.7.7+, just like with the introduction of bool in 2.2.1. This will be a mess unless adoption of new Python minor versions is swift and consistent. The PEP says that new features should be testable with feature detection, but how far does that go? The Python 3 NPN interface is a method of SSLContext, which didn't exist in 2.7. Do we backport the entire SSLContext interface in a minor release, or introduce a new NPN interface that is not based on SSLContext just for older Pythons? The whole thing. Have you first tried to do it and appreciate the amount of disruption it would cause? It's not just ssl2: you needs os2, random2, ftplib2, poplib2, imaplib2, smtplib2. You also run headlong into the problem of a complex external dependency on OpenSSL (which the Linux distro repackagers currently handle for us). So are you proposing to backport changes to all these modules too? This sounds crazy. 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat, Mar 22, 2014, at 16:34, Antoine Pitrou wrote: On Sun, 23 Mar 2014 09:08:29 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 23 March 2014 08:53, Ben Darnell b...@bendarnell.com wrote: I agree wholeheartedly with the sentiment behind this PEP, but I have concerns about the implementation. If we introduce new APIs into the ssl module then we will see packages and applications that depend on Python 2.7.7+, just like with the introduction of bool in 2.2.1. This will be a mess unless adoption of new Python minor versions is swift and consistent. The PEP says that new features should be testable with feature detection, but how far does that go? The Python 3 NPN interface is a method of SSLContext, which didn't exist in 2.7. Do we backport the entire SSLContext interface in a minor release, or introduce a new NPN interface that is not based on SSLContext just for older Pythons? The whole thing. Have you first tried to do it and appreciate the amount of disruption it would cause? It's not just ssl2: you needs os2, random2, ftplib2, poplib2, imaplib2, smtplib2. You also run headlong into the problem of a complex external dependency on OpenSSL (which the Linux distro repackagers currently handle for us). So are you proposing to backport changes to all these modules too? This sounds crazy. If one reads the PEP, one will notice it indeed proposes a conditional exception for networking related modules that depend on one or more of the network security related modules [ssl, hashlib,...]. ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan ncogh...@gmail.com wrote: The issue isn't really the ssl module itself - it's the other modules that *depend* on the ssl module (like httplib, urllib, poplib, ftplib, imaplib). You could technically try to monkeypatch or shadow the stdlib ssl module from a third party library, but that's a *really* dangerous approach to security (since it makes it hard to do proper integration testing). I suppose the difference is that the applications I've worked with have *already* abandoned stdlib modules like httplib or urllib in favor of libraries like requests and tornado, so I see this as mainly a question of whether the stdlib provides a suitable foundation for those packages. The argument about the difficulty of integration testing cuts both ways - I can use tox to test Tornado with several versions of a third-party package, but cannot (as long as https://launchpad.net/~fkrull/+archive/deadsnakesonly provides one package per x.y release) easily test with both Python 2.7.6 and 2.7.7. In my experience most deployments of Python apps have better systems in place to deal with packages installed from PyPI than new versions of Python itself. Therefore it might be better to follow the lead of the unittest2 module and introduce a new ssl2 module that tracks the most recent version of Python's ssl module. My counter-proposal is: * Introduce a new module 'ssl2' which is essentially a backport of the current release's ssl module for all old versions of Python that anyone cares to support. It's not just ssl2: you needs os2, random2, ftplib2, poplib2, imaplib2, smtplib2. You also run headlong into the problem of a complex external dependency on OpenSSL (which the Linux distro repackagers currently handle for us). Just os2 and random2; as I said a few bullet points down the stdlib libraries that use ssl would be sufficient justification for additions to the ssl module's interface. This is what the reimplementing substantial portions of the standard library as third party modules to gain access to the newer underlying network security protocols and mechanisms, and then injecting those into the module namespace to override their standard library counterparts. comment is about, but I guess I should expand on that for the benefit of readers not as familiar with the relevant implementation details. In my proposal there is no monkey-patching; the newer ssl interfaces would come solely from the ssl2 module. * Third-party applications and libraries targeting anything but the latest version of Python are advised to use ssl2 instead of ssl (this might also be a good opportunity to bless certifi or an equivalent). * Minor releases of Python are allowed to make any security-related change that does not change any public interfaces (e.g. linking against a new version of openssl, or disabling SSLv2) New versions of OpenSSL are nowhere near as useful when their constants aren't made available in the Python API. * New interfaces in security-related modules are allowed only if those new interfaces are used by other stdlib modules (since stdlib modules are the only place where ssl2 is off-limits). For example, a backport of match_hostname could go in if httplib or urllib used it. NPN/ALPN would not be allowed under this rule since there is no stdlib code that uses them; third-party SPDY or HTTP/2 code would have to use ssl2 to get this interface. In this world, libraries like requests or tornado that want to use advanced ssl features can simply declare a dependency on ssl2, instead of saying we require Python 2.7.7+, 3.2.6+, etc. There's a reason the developers of those libraries haven't already done that: it's genuinely hard. It's not that I didn't think of this approach, it's that I think it would actually be more difficult and less effective than the approach currently in the PEP. One of the reasons it's genuinely hard is that no one has provided an interface compatible with the stdlib ssl module. An ssl2 module that backported Python 3.4's ssl module would be a *much* more attractive porting target than e.g. PyOpenSSL. -Ben Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
In the case of requests they already have an optional dependency on pyopenssl. It's just many people either don't know they should use it, are unable to use it, or unwilling to use the python packaging tool chain because of its current flaws. On Mar 22, 2014, at 7:42 PM, Ben Darnell b...@bendarnell.com wrote: On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan ncogh...@gmail.com wrote: The issue isn't really the ssl module itself - it's the other modules that *depend* on the ssl module (like httplib, urllib, poplib, ftplib, imaplib). You could technically try to monkeypatch or shadow the stdlib ssl module from a third party library, but that's a *really* dangerous approach to security (since it makes it hard to do proper integration testing). I suppose the difference is that the applications I've worked with have *already* abandoned stdlib modules like httplib or urllib in favor of libraries like requests and tornado, so I see this as mainly a question of whether the stdlib provides a suitable foundation for those packages. The argument about the difficulty of integration testing cuts both ways - I can use tox to test Tornado with several versions of a third-party package, but cannot (as long as https://launchpad.net/~fkrull/+archive/deadsnakes only provides one package per x.y release) easily test with both Python 2.7.6 and 2.7.7. In my experience most deployments of Python apps have better systems in place to deal with packages installed from PyPI than new versions of Python itself. Therefore it might be better to follow the lead of the unittest2 module and introduce a new ssl2 module that tracks the most recent version of Python's ssl module. My counter-proposal is: * Introduce a new module 'ssl2' which is essentially a backport of the current release's ssl module for all old versions of Python that anyone cares to support. It's not just ssl2: you needs os2, random2, ftplib2, poplib2, imaplib2, smtplib2. You also run headlong into the problem of a complex external dependency on OpenSSL (which the Linux distro repackagers currently handle for us). Just os2 and random2; as I said a few bullet points down the stdlib libraries that use ssl would be sufficient justification for additions to the ssl module's interface. This is what the reimplementing substantial portions of the standard library as third party modules to gain access to the newer underlying network security protocols and mechanisms, and then injecting those into the module namespace to override their standard library counterparts. comment is about, but I guess I should expand on that for the benefit of readers not as familiar with the relevant implementation details. In my proposal there is no monkey-patching; the newer ssl interfaces would come solely from the ssl2 module. * Third-party applications and libraries targeting anything but the latest version of Python are advised to use ssl2 instead of ssl (this might also be a good opportunity to bless certifi or an equivalent). * Minor releases of Python are allowed to make any security-related change that does not change any public interfaces (e.g. linking against a new version of openssl, or disabling SSLv2) New versions of OpenSSL are nowhere near as useful when their constants aren't made available in the Python API. * New interfaces in security-related modules are allowed only if those new interfaces are used by other stdlib modules (since stdlib modules are the only place where ssl2 is off-limits). For example, a backport of match_hostname could go in if httplib or urllib used it. NPN/ALPN would not be allowed under this rule since there is no stdlib code that uses them; third-party SPDY or HTTP/2 code would have to use ssl2 to get this interface. In this world, libraries like requests or tornado that want to use advanced ssl features can simply declare a dependency on ssl2, instead of saying we require Python 2.7.7+, 3.2.6+, etc. There's a reason the developers of those libraries haven't already done that: it's genuinely hard. It's not that I didn't think of this approach, it's that I think it would actually be more difficult and less effective than the approach currently in the PEP. One of the reasons it's genuinely hard is that no one has provided an interface compatible with the stdlib ssl module. An ssl2 module that backported Python 3.4's ssl module would be a *much* more attractive porting target than e.g. PyOpenSSL. -Ben Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/donald%40stufft.io ___ Python-Dev mailing list
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 22 March 2014 23:49, Donald Stufft don...@stufft.io wrote: In the case of requests they already have an optional dependency on pyopenssl. It's just many people either don't know they should use it, are unable to use it, or unwilling to use the python packaging tool chain because of its current flaws. Do they use the new features in the Python 3.x ssl module when it's available to give the same level of security as having pyopenssl would, or do they use a lowest common denominator (i.e., 2.x compatible) level of security when using the stdlib? If the latter, that would be very, very sad. Paul ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Also important to remember that pip itself uses the OpenSSL binding in the ssl module so there is a chicken and egg problem. On Mar 22, 2014, at 7:49 PM, Donald Stufft don...@stufft.io wrote: In the case of requests they already have an optional dependency on pyopenssl. It's just many people either don't know they should use it, are unable to use it, or unwilling to use the python packaging tool chain because of its current flaws. On Mar 22, 2014, at 7:42 PM, Ben Darnell b...@bendarnell.com wrote: On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan ncogh...@gmail.com wrote: The issue isn't really the ssl module itself - it's the other modules that *depend* on the ssl module (like httplib, urllib, poplib, ftplib, imaplib). You could technically try to monkeypatch or shadow the stdlib ssl module from a third party library, but that's a *really* dangerous approach to security (since it makes it hard to do proper integration testing). I suppose the difference is that the applications I've worked with have *already* abandoned stdlib modules like httplib or urllib in favor of libraries like requests and tornado, so I see this as mainly a question of whether the stdlib provides a suitable foundation for those packages. The argument about the difficulty of integration testing cuts both ways - I can use tox to test Tornado with several versions of a third-party package, but cannot (as long as https://launchpad.net/~fkrull/+archive/deadsnakes only provides one package per x.y release) easily test with both Python 2.7.6 and 2.7.7. In my experience most deployments of Python apps have better systems in place to deal with packages installed from PyPI than new versions of Python itself. Therefore it might be better to follow the lead of the unittest2 module and introduce a new ssl2 module that tracks the most recent version of Python's ssl module. My counter-proposal is: * Introduce a new module 'ssl2' which is essentially a backport of the current release's ssl module for all old versions of Python that anyone cares to support. It's not just ssl2: you needs os2, random2, ftplib2, poplib2, imaplib2, smtplib2. You also run headlong into the problem of a complex external dependency on OpenSSL (which the Linux distro repackagers currently handle for us). Just os2 and random2; as I said a few bullet points down the stdlib libraries that use ssl would be sufficient justification for additions to the ssl module's interface. This is what the reimplementing substantial portions of the standard library as third party modules to gain access to the newer underlying network security protocols and mechanisms, and then injecting those into the module namespace to override their standard library counterparts. comment is about, but I guess I should expand on that for the benefit of readers not as familiar with the relevant implementation details. In my proposal there is no monkey-patching; the newer ssl interfaces would come solely from the ssl2 module. * Third-party applications and libraries targeting anything but the latest version of Python are advised to use ssl2 instead of ssl (this might also be a good opportunity to bless certifi or an equivalent). * Minor releases of Python are allowed to make any security-related change that does not change any public interfaces (e.g. linking against a new version of openssl, or disabling SSLv2) New versions of OpenSSL are nowhere near as useful when their constants aren't made available in the Python API. * New interfaces in security-related modules are allowed only if those new interfaces are used by other stdlib modules (since stdlib modules are the only place where ssl2 is off-limits). For example, a backport of match_hostname could go in if httplib or urllib used it. NPN/ALPN would not be allowed under this rule since there is no stdlib code that uses them; third-party SPDY or HTTP/2 code would have to use ssl2 to get this interface. In this world, libraries like requests or tornado that want to use advanced ssl features can simply declare a dependency on ssl2, instead of saying we require Python 2.7.7+, 3.2.6+, etc. There's a reason the developers of those libraries haven't already done that: it's genuinely hard. It's not that I didn't think of this approach, it's that I think it would actually be more difficult and less effective than the approach currently in the PEP. One of the reasons it's genuinely hard is that no one has provided an interface compatible with the stdlib ssl module. An ssl2 module that backported Python 3.4's ssl module would be a *much* more attractive porting target than e.g. PyOpenSSL. -Ben Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
They detect for ssl to have the SSLContext and use it if it's available. On Mar 22, 2014, at 7:54 PM, Paul Moore p.f.mo...@gmail.com wrote: On 22 March 2014 23:49, Donald Stufft don...@stufft.io wrote: In the case of requests they already have an optional dependency on pyopenssl. It's just many people either don't know they should use it, are unable to use it, or unwilling to use the python packaging tool chain because of its current flaws. Do they use the new features in the Python 3.x ssl module when it's available to give the same level of security as having pyopenssl would, or do they use a lowest common denominator (i.e., 2.x compatible) level of security when using the stdlib? If the latter, that would be very, very sad. Paul ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sun, Mar 23, 2014 at 10:33 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 22 Mar 2014 19:07:51 -0400 Donald Stufft don...@stufft.io wrote: As someone who is deeply biased towards improving the packaging tool chain and getting people to use it I think that most people will simply use the Stdlib even if a more secure alternative exists. Infact one does exist and I still see almost everyone using the stdlib ssl instead of pyopenssl. pyopenssl exposes a different API from ssl, though. It's not just a matter of flipping an import statement. How hard would it be to create a wrapper module named ssl.py, which imports pyopenssl (thus taking advantage of any updates it gets), and could be placed earlier in the search path than the stdlib one? I'm +1 on the overall concept, but not sure about 2.6 and older. 2.7 is already a bit of an odd duck; it's being supported for longer than its official Windows compiler, it's going to be supported by Red Hat until eternity and beyond, and it wouldn't in the least surprise me if 2.7.10 introduces a bit of stuff, backported, in ways that are fundamentally security fixes. Is it really that bad to have something depend on 2.7.10 rather than 2.7.0? If a program will bomb without some bugfix, then it's not unreasonable to say that it depends on a version of Python that includes that fix. As long as any program written for 2.7.0 will run on 2.7.x unchanged (the normal expectations with semantic versioning), I don't see a problem with some of the bug fixes actually adding attributes; imagine if some feature attribute were simply misspelled in the previous versions, which could surely be fixed in a point release; it's not going to break anything. ChrisA ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat, 22 Mar 2014 23:54:37 +0100 Thomas Wouters tho...@python.org wrote: Or not rely on the standard library for their security. Much as I realize it is necessary for rudimentary SSL support (for example) to exist in the standard library, Unfortunately, rudimentary SSL support is worse than nothing. 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sun, 23 Mar 2014 10:59:22 +1100 Chris Angelico ros...@gmail.com wrote: Is it really that bad to have something depend on 2.7.10 rather than 2.7.0? It makes our whole release and versioning scheme very confusing (hopefully people will not have to read Nick's PEP to understand it :-)). 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23.03.2014 01:01, Antoine Pitrou wrote: 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) True, you may blame me for the situation. Only a handful of people were interested in the XML issues. I ran out of steam and moved to more sapid topics, too. Christian ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 Mar 2014 10:18, Christian Heimes christ...@python.org wrote: On 23.03.2014 01:01, Antoine Pitrou wrote: 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) True, you may blame me for the situation. Only a handful of people were interested in the XML issues. I ran out of steam and moved to more sapid topics, too. The key difference there is we're not reliant on defusedxml to download defusedxml :) Anyway, folks have given me plenty of good feedback to chew over. I'm going to go run some errands and then try to get a new revision posted this afternoon. Cheers, Nick. Christian ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sun, 23 Mar 2014 01:01:38 +0100, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 23 Mar 2014 07:11:07 +1000 Nick Coghlan ncogh...@gmail.com wrote: 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. Yeah, I couldn't figure out what this paragraph meant. What does backporting features in maintenance releases have to do with making feature releases secure by default? If we are not relaxing the backward compatibility rules we can't do secure by default changes in a maintenance release...and if we don't do that, thinking that very much legacy software is going to get upgraded to use the new more secure capabilities is, I suspect (but cannot prove, obviously) mostly wishful thinking. An exception might be be commercial packages, but even there I wouldn't bet very many bucks. It seems to me that shops who are being security concious enough to be candidates for modifying currently deployed packages to be more secure are also likely to have already addressed the security issues in some other way. Now, requests and other libraries could use these new features, and since they have faster release cycles, they could presumably make the increased security be the default sooner. So that's what I see as the argument in favor...but it is a much narrower impact area than most python software that uses ssl, and certainly doesn't cover poplib, smtplib, etc. But perhaps I am being overly cynical. Regardless, like Martin, I prefer to focus on Python3. --David ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Am 23.03.14 01:15, schrieb Christian Heimes: On 23.03.2014 01:01, Antoine Pitrou wrote: 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) True, you may blame me for the situation. Only a handful of people were interested in the XML issues. I ran out of steam and moved to more sapid topics, too I don't think anybody wanted to assign blame (although I can sympathize with your urge to accept the blame). The fact is that this is a volunteer project: we do what we can and have fun doing. Regards, Martin ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 10:08, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 22 Mar 2014 23:54:37 +0100 Thomas Wouters tho...@python.org wrote: Or not rely on the standard library for their security. Much as I realize it is necessary for rudimentary SSL support (for example) to exist in the standard library, Unfortunately, rudimentary SSL support is worse than nothing. I'm going to try to find a way to steal that line and get it into the PEP. I'm not sure yet if my proposal is the *right* answer, but this observation gets right to the heart of the problem that actually needs to be solved. I'd actually welcome a competing PEP that seriously explored separating out the relevant parts of the Python 3.4 standard library as a PyPI project and attempted to tackle the problem by making that available at least as far back as 2.7 and then just deprecating the leaking batteries in the 2.7 standard library. Just because I think that approach would be even more work and even more disruptive than what I propose in PEP 466, doesn't mean it isn't a better idea overall. What we have essentially found is that where we could basically get away with an 18 month update cycle for improved network security support (extended out to a few years by certain major platform vendors), that approach *isn't* working when it comes to putting a feature release into long term maintenance mode. I don't think the situation isn't critical yet, but it's getting close, and I think we need to deal with it within the 12 months (and preferably sooner than that). My PEP proposes one way of addressing the challenge: allowing a wider variety of changes in maintenance releases to reduce the variance in capability in this area. Moving the affected modules out of the standard library proper and bundling the critical ones along with pip instead is indeed another alternative. However, that approach introduces additional issues of its own - I'll cover some of them in the next PEP update, but it would be good to have someone explicitly trying to make the case that a PyPI backport would be simpler for the overall ecosystem than my suggested approach. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On 23 March 2014 10:40, Martin v. Löwis mar...@v.loewis.de wrote: Am 23.03.14 01:15, schrieb Christian Heimes: On 23.03.2014 01:01, Antoine Pitrou wrote: 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) True, you may blame me for the situation. Only a handful of people were interested in the XML issues. I ran out of steam and moved to more sapid topics, too I don't think anybody wanted to assign blame (although I can sympathize with your urge to accept the blame). The fact is that this is a volunteer project: we do what we can and have fun doing. Agreed completely - what I'm trying to do here is set up a plan that is at least *acceptable* to the upstream community, so we can then seek corporate support for actually putting it into practice (and I'd advise against us accepting *any* proposal to resolve the situation without receiving binding commitments to provide ongoing maintenance support - while I think this proposal is important, I'm under no illusions that actually implementing it will be fun, and it's not appropriate to ask people to do that in their own time). However, we have a *lot* of downstream users and redistributors that have been taking CPython core development for granted, and by so doing, they have allowed a situation to develop that has some rather negative implications for the overall security of networked communications in the Python ecosystem. Since some of those same corporate redistributors are a key enabler allowing users to stay on those old releases that are no longer supported upstream, and others are likely to be being conservative in their own Python 3 migrations, I believe they share a lot of the responsibility for helping to resolve it, either by facilitating the migration to Python 3, helping to improve the networking security situation in Python 2, or, preferably, both. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sun, 23 Mar 2014 01:40:32 +0100 Martin v. Löwis mar...@v.loewis.de wrote: Am 23.03.14 01:15, schrieb Christian Heimes: On 23.03.2014 01:01, Antoine Pitrou wrote: 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) True, you may blame me for the situation. Only a handful of people were interested in the XML issues. I ran out of steam and moved to more sapid topics, too I don't think anybody wanted to assign blame (although I can sympathize with your urge to accept the blame). The fact is that this is a volunteer project: we do what we can and have fun doing. Indeed this wasn't meant to blame anyone, simply to point out that improving security is often hampered by lack of manpower or motivation. 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 22, 2014, at 8:55 PM, Nick Coghlan ncogh...@gmail.com wrote: Moving the affected modules out of the standard library proper and bundling the critical ones along with pip instead is indeed another alternative. However, that approach introduces additional issues of its own - I'll cover some of them in the next PEP update, but it would be good to have someone explicitly trying to make the case that a PyPI backport would be simpler for the overall ecosystem than my suggested approach. FWIW pip as of right now has a policy of no C dependencies outside of the stdlib. CPython isn’t our only target and C dependencies don’t work very well on PyPy (if at all) and it makes the situation much more difficult on platforms where there are no compiler toolchains (Windows). - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
I'm a bit under the weather and I'm not sure what to think of this yet. With that provision, and trying to be brief: I agree that there are security concerns about Python 2.7 that can't be addressed by recommending Python 3.4 instead. I also agree that the ban on new features in old releases can be stifling. But I also worry about breaking working code. I am a bit worried that writing a PEP (at least this specific PEP) would become less about arguing for a specific technical (or even political) idea, and more about putting weasel words in an official document so that it can be used to justify future actions without due process. I wonder whether there is a specific narrower proposal (e.g. add SSLContext to Python 2.7.7?) that would make the discussion more concrete. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan ncogh...@gmail.com wrote: On 23 March 2014 10:08, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 22 Mar 2014 23:54:37 +0100 Thomas Wouters tho...@python.org wrote: Or not rely on the standard library for their security. Much as I realize it is necessary for rudimentary SSL support (for example) to exist in the standard library, Unfortunately, rudimentary SSL support is worse than nothing. I'm going to try to find a way to steal that line and get it into the PEP. I'm not sure yet if my proposal is the *right* answer, but this observation gets right to the heart of the problem that actually needs to be solved. I'd actually welcome a competing PEP that seriously explored separating out the relevant parts of the Python 3.4 standard library as a PyPI project and attempted to tackle the problem by making that available at least as far back as 2.7 and then just deprecating the leaking batteries in the 2.7 standard library. Now I have been reading this thread on my phone and I only have cursory understanding of what failure ssl has had as of late, so this might be stupid, but what if in Python 3.5 we made it so people passed in an explicit SSL object into the relevant APIs and threw an exception if one wasn't provided when trying to access something requiring SSL? Then the ssl module would start existing on PyPI to make sure it can evolve faster than every 18 months? I know this doesn't help older APIs but it would make it rather explicit going forward that if you want security you need the latest thing and that's found on PyPI so it would at least solve the issue for the future which is better than nothing. We could try to provide matching APIs that monkey-patch older versions of Python if that's so desired to make this backwards-compatible, but as we all know that can be rather brittle. -Brett Just because I think that approach would be even more work and even more disruptive than what I propose in PEP 466, doesn't mean it isn't a better idea overall. What we have essentially found is that where we could basically get away with an 18 month update cycle for improved network security support (extended out to a few years by certain major platform vendors), that approach *isn't* working when it comes to putting a feature release into long term maintenance mode. I don't think the situation isn't critical yet, but it's getting close, and I think we need to deal with it within the 12 months (and preferably sooner than that). My PEP proposes one way of addressing the challenge: allowing a wider variety of changes in maintenance releases to reduce the variance in capability in this area. Moving the affected modules out of the standard library proper and bundling the critical ones along with pip instead is indeed another alternative. However, that approach introduces additional issues of its own - I'll cover some of them in the next PEP update, but it would be good to have someone explicitly trying to make the case that a PyPI backport would be simpler for the overall ecosystem than my suggested approach. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/ brett%40python.org ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 22, 2014, at 9:17 PM, Ben Darnell b...@bendarnell.com wrote: On Sat, Mar 22, 2014 at 8:55 PM, Nick Coghlan ncogh...@gmail.com wrote: What we have essentially found is that where we could basically get away with an 18 month update cycle for improved network security support (extended out to a few years by certain major platform vendors), that approach *isn't* working when it comes to putting a feature release into long term maintenance mode. I don't think the situation isn't critical yet, but it's getting close, and I think we need to deal with it within the 12 months (and preferably sooner than that). This PEP as written applies to both Python 2.x and 3.x, but the two situations are very different. 3.x is on a ~18 month update cycle, so why isn't the status quo acceptable there? Python 2.x has less than 18 months of support left, so could it get by with a single exceptional release instead of a general relaxing of the rules? (if it were up to me, I'd call that release Python 2.8 instead of 2.7.7) If this PEP is mainly about a one-shot update to the security components of Python 2.x, I'd like to see an explicit list of what is in scope for the update. -Ben ___ 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/donald%40stufft.io As one of the instigators who convinced Nick to write this PEP I’m far less concerned about back porting things to earlier 3.x releases than I am about getting things into 2.7 at this point. Going from 3.2 to 3.4 is not terribly difficult if it requires any work at all. Going from 2.7 to 3.4 is often times a significant investment in resources that has to be taken by *every* network using project. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
On Mar 22, 2014, at 9:33 PM, Brett Cannon bcan...@gmail.com wrote: On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan ncogh...@gmail.com wrote: On 23 March 2014 10:08, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 22 Mar 2014 23:54:37 +0100 Thomas Wouters tho...@python.org wrote: Or not rely on the standard library for their security. Much as I realize it is necessary for rudimentary SSL support (for example) to exist in the standard library, Unfortunately, rudimentary SSL support is worse than nothing. I'm going to try to find a way to steal that line and get it into the PEP. I'm not sure yet if my proposal is the *right* answer, but this observation gets right to the heart of the problem that actually needs to be solved. I'd actually welcome a competing PEP that seriously explored separating out the relevant parts of the Python 3.4 standard library as a PyPI project and attempted to tackle the problem by making that available at least as far back as 2.7 and then just deprecating the leaking batteries in the 2.7 standard library. Now I have been reading this thread on my phone and I only have cursory understanding of what failure ssl has had as of late, so this might be stupid, but what if in Python 3.5 we made it so people passed in an explicit SSL object into the relevant APIs and threw an exception if one wasn't provided when trying to access something requiring SSL? Then the ssl module would start existing on PyPI to make sure it can evolve faster than every 18 months? It’s not really a failure so much as what was concerned secure in 2010 isn’t the case in 2014. I don’t want to sounds like I’m trying to say that pip should dictate Python policy or anything but pip more or less depends on the fact that ssl is available in the stdlib at this point in time in order to be able to handle secure downloads. Every 18 months isn’t that big of a deal tbh, the larger concern is Python 2.7 which has had nearly 4 years since it’s release and is likely to exist for far more years past that. I know this doesn't help older APIs but it would make it rather explicit going forward that if you want security you need the latest thing and that's found on PyPI so it would at least solve the issue for the future which is better than nothing. We could try to provide matching APIs that monkey-patch older versions of Python if that's so desired to make this backwards-compatible, but as we all know that can be rather brittle. -Brett Just because I think that approach would be even more work and even more disruptive than what I propose in PEP 466, doesn't mean it isn't a better idea overall. What we have essentially found is that where we could basically get away with an 18 month update cycle for improved network security support (extended out to a few years by certain major platform vendors), that approach *isn't* working when it comes to putting a feature release into long term maintenance mode. I don't think the situation isn't critical yet, but it's getting close, and I think we need to deal with it within the 12 months (and preferably sooner than that). My PEP proposes one way of addressing the challenge: allowing a wider variety of changes in maintenance releases to reduce the variance in capability in this area. Moving the affected modules out of the standard library proper and bundling the critical ones along with pip instead is indeed another alternative. However, that approach introduces additional issues of its own - I'll cover some of them in the next PEP update, but it would be good to have someone explicitly trying to make the case that a PyPI backport would be simpler for the overall ecosystem than my suggested approach. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/brett%40python.org ___ 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/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
