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 wrote: > Am 26.03.2014 00:06, schrieb Nick Coghlan: > > > > On 26 Mar 2014 08:32, "Georg Brandl" > > wrote: > >> > >> Am 25.03.2014 23:15, schrieb Nick Coghlan: > >> > > >> > On 26 Mar 2014 01:19, "Brett Cannon" >

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" > wrote: >> >> Am 25.03.2014 23:15, schrieb Nick Coghlan: >> > >> > On 26 Mar 2014 01:19, "Brett Cannon" >> >

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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 26 Mar 2014 08:32, "Georg Brandl" wrote: > > Am 25.03.2014 23:15, schrieb Nick Coghlan: > > > > On 26 Mar 2014 01:19, "Brett Cannon" > > wrote: > >> As long as we make it clear we have chosen to change our > > backwards-compatibility guarantees in the name of security

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" > 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 releas

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 26 Mar 2014 01:19, "Brett Cannon" 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 c

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 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 > >

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 25 March 2014 09:01, Chris Angelico 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 24 March 2014 19:37, Chris Angelico 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. I

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 25 March 2014 08:26, Chris Angelico 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Tue, Mar 25, 2014 at 7:37 PM, Cory Benfield wrote: > On 25 March 2014 08:26, Chris Angelico 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; a

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Tue, Mar 25, 2014 at 7:12 PM, Cory Benfield wrote: > On 24 March 2014 19:37, Chris Angelico 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 tha

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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 25 March 2014 12:25, MRAB wrote: > On 2014-03-25 01:29, Ben Darnell wrote: >> >> On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan > > wrote: >> >> >> On 24 Mar 2014 15:25, "Chris Angelico" > > wrote: >> >> > As has already been point

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 2014-03-25 01:29, Ben Darnell wrote: On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote: On 24 Mar 2014 15:25, "Chris Angelico" mailto:ros...@gmail.com>> wrote: > As has already been pointed out, this can already happen, but in an > ad-hoc way. Mak

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan wrote: > > On 24 Mar 2014 15:25, "Chris Angelico" 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" w

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 8:28 PM, Cory Benfield wrote: > On 24 March 2014 08:44, Nick Coghlan 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 redistributor

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 cre

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 24 March 2014 08:44, Nick Coghlan 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 t

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 25 March 2014 00:36, Nick Coghlan wrote: > On 25 March 2014 00:18, Skip Montanaro 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 25 March 2014 00:18, Skip Montanaro wrote: > On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan 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 P

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, 23 Mar 2014 21:31:12 -0400, Barry Warsaw 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan 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 evo

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 24 March 2014 23:49, Skip Montanaro 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, Mar 23, 2014 at 7:03 PM, Barry Warsaw 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: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 7:44 PM, Nick Coghlan wrote: > > On 24 Mar 2014 15:25, "Chris Angelico" 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 24 Mar 2014 15:25, "Chris Angelico" 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 1:34 PM, Donald Stufft 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 23, 2014, at 9:31 PM, Barry Warsaw 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

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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 23, 2014, at 8:31 PM, Jesse Noller wrote: > > >> On Mar 23, 2014, at 7: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

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

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-i

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mon, Mar 24, 2014 at 11:03 AM, Barry Warsaw 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 o

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

> On Mar 23, 2014, at 7: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)

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 relea

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 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 w

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 24 Mar 2014 09:27, "Barry Warsaw" 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 s

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) bu

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 impl

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 wrote: > >> On Sun, 23 Mar 2014 07:29:07 + >> Cory Benfield wrote: >>> This is an interesting idea. My biggest problem with it is that, at least >>> with the ssl library, these aren’t server-only pr

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 23, 2014, at 11:34 AM, Antoine Pitrou wrote: > On Sun, 23 Mar 2014 07:29:07 + > 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 >>> enhancem

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, 23 Mar 2014 07:29:07 + 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 rele

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 applicatio

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 22 March 2014 21:11, Nick Coghlan 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 negl

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy 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 th

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 Mar 2014 20:33, "Victor Stinner" 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/C

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

Hi, 2014-03-23 11:17 GMT+01:00 : > Quoting Victor Stinner : >> 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 dev

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

Quoting Victor Stinner : 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

Hi, 2014-03-22 22:11 GMT+01:00 Nick Coghlan : > 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 compo

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 A

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 3/22/2014 8:55 PM, Nick Coghlan wrote: 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 proble

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 Mar 2014 11:47, "Donald Stufft" wrote: > > > On Mar 22, 2014, at 9:33 PM, Brett Cannon wrote: > >> >> >> On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan wrote: >>> >>> On 23 March 2014 10:08, Antoine Pitrou wrote: >>> > On Sat, 22 Mar 2014 23:54:37 +0100 >>> > Thomas Wouters wrote: >>> >>

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 22, 2014, at 9:33 PM, Brett Cannon wrote: > > > On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan wrote: > On 23 March 2014 10:08, Antoine Pitrou wrote: > > On Sat, 22 Mar 2014 23:54:37 +0100 > > Thomas Wouters wrote: > >> > >> Or not rely on the standard library for their security. Muc

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 22, 2014, at 9:17 PM, Ben Darnell wrote: > On Sat, Mar 22, 2014 at 8:55 PM, Nick Coghlan 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

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 wrote: > On 23 March 2014 10:08, Antoine Pitrou wrote: > > On Sat, 22 Mar 2014 23:54:37 +0100 > > Thomas Wouters wrote: > >> > >> Or not rely on the standard library for their security. Much as I > realize > >> it is necessary for rudimentary SSL s

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 b

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Mar 22, 2014, at 8:55 PM, Nick Coghlan 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

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" 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 > >> crypt

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sat, Mar 22, 2014 at 8:55 PM, Nick Coghlan 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 10:40, "Martin v. Löwis" 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 10:08, Antoine Pitrou wrote: > On Sat, 22 Mar 2014 23:54:37 +0100 > Thomas Wouters 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, > > Unfortun

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 examp

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, 23 Mar 2014 01:01:38 +0100, Antoine Pitrou wrote: > On Sun, 23 Mar 2014 07:11:07 +1000 > Nick Coghlan 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 prov

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 Mar 2014 10:18, "Christian Heimes" 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. > > > >

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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, 23 Mar 2014 10:59:22 +1100 Chris Angelico 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 Antoi

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sat, 22 Mar 2014 23:54:37 +0100 Thomas Wouters 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.

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, 23 Mar 2014 07:11:07 +1000 Nick Coghlan 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 differe

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, Mar 23, 2014 at 10:33 AM, Antoine Pitrou wrote: > On Sat, 22 Mar 2014 19:07:51 -0400 > Donald Stufft 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

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 wrote: > >> On 22 March 2014 23:49, Donald Stufft wrote: >> In the case of requests they already have an optional dependency on >> pyopenssl. It's just many people either don't kn

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 wrote: > > In the case of requests they already have an optional dependency on > pyopenssl. It's just many people either do

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 22 March 2014 23:49, Donald Stufft 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. D

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 wrote:

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan 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 thi

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 wrote: > > On 23 March 2014 08:53, Ben Darnell wrote: > > > I agree wholeheartedly with the sentiment behind this PEP, but I have > > > concerns about the implementation. If we introduce new

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sun, 23 Mar 2014 09:08:29 +1000 Nick Coghlan wrote: > On 23 March 2014 08:53, Ben Darnell 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 appl

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Sat, 22 Mar 2014 19:07:51 -0400 Donald Stufft 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 09:07, Donald Stufft 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 ev

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 07:32, Benjamin Peterson 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 22 March 2014 23:07, Donald Stufft 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 ev

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

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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 08:53, Ben Darnell 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 intr

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. A

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

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" wrote: > 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 > soft

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 unle

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 08: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'

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.c

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 migra

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 08:16, "Martin v. Löwis" 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 t

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

In article , Nick Coghlan 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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 08:23, "Martin v. Löwis" 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? Unfortuna

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

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On 23 March 2014 08:14, "Martin v. Löwis" 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

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-o

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 comi

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" wrote: > > Am 22.03.14 22:17, schrieb Cory Benfield: >> I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7 >> i

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 mi

  1   2   >