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] SSLSocket.send() for non-blocking sockets

Chris Angelico writes: > On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath wrote: >> 2. Change the behavior immediately, potentially breaking some >>applications that worked around it, but unbreaking others that relied >>on the documented behavior. > > If it's a functionality change that's

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 461: Adding % formatting to bytes and bytearray -- Final, Take 3

I love it. On Tue, Mar 25, 2014 at 6:37 PM, Ethan Furman wrote: > Okay, I included that last round of comments (from late February). > > Barring typos, this should be the final version. > > Final comments? > > - > PEP: 46

[Python-Dev] C code: %s vs %U

%s is a string. %U is unicode? If so, then %s should only be used when it is certain the string in question has no unicode in it? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubsc

Re: [Python-Dev] SSLSocket.send() for non-blocking sockets

On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath wrote: > 2. Change the behavior immediately, potentially breaking some >applications that worked around it, but unbreaking others that relied >on the documented behavior. If it's a functionality change that's likely to break code, would it b

[Python-Dev] SSLSocket.send() for non-blocking sockets

Hello, I'd like to hear some more opinions on http://bugs.python.org/issue20951. I think the possible courses of action are: 1. Document the current behavior. This has the drawback that (a) it still remains rather counterintuitive, and (b) one still needs extra code to distinguish betwe

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

At this I think this PEP has become a little too vague and abstract, and I think we'd probably be better served by getting more concrete: Problem: Some of Python 2's modules which are fundamentally necessary for interop with the broader internet, and the security thereof, are missing really impor

[Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

Okay, I included that last round of comments (from late February). Barring typos, this should be the final version. Final comments? - PEP: 461 Title: Adding % formatting to bytes and bytearray Version: $Revision$ Last-M

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

On Tue, 25 Mar 2014 16:14:04 -0700 Guido van Rossum wrote: > That would be a rather strong unilateral decision. Why don't you ask the > authors? In theory the PEP's proposals could serve in situations where > asyncio isn't appropriate, and asyncio's subprocess I/O isn't the smoothest > API imagina

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On Mar 25, 2014, at 7:03 PM, Nick Coghlan wrote: > > On 26 Mar 2014 08:35, "Antoine Pitrou" wrote: > > > > On Tue, 25 Mar 2014 23:09:45 +1000 > > Nick Coghlan wrote: > > > > > > Alternative: selectively backport particular APIs > > > - > > > > >

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

That would be a rather strong unilateral decision. Why don't you ask the authors? In theory the PEP's proposals could serve in situations where asyncio isn't appropriate, and asyncio's subprocess I/O isn't the smoothest API imaginable. (In practice I'm not sure if the PEP would have been written wi

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

On 26 Mar 2014 08:22, "Antoine Pitrou" wrote: > > > Hi, > > On core-mentorship someone asked about PEP 3145 - Asynchronous I/O for > subprocess.popen. I answered that asyncio now has subprocess support > (including non-blocking I/O on the three standard stream pipes), so > it's not obvious anythi

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 (round 4): Python 2.7 network security enhancements

On 26 Mar 2014 08:35, "Antoine Pitrou" wrote: > > On Tue, 25 Mar 2014 23:09:45 +1000 > Nick Coghlan wrote: > > > > Alternative: selectively backport particular APIs > > - > > > > An instinctively minimalist reaction to this proposal is to only backp

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On 26 Mar 2014 00:25, "Paul Moore" wrote: > > On 25 March 2014 13:47, Nick Coghlan wrote: > > It's not like we're going to just be giving the PEP to vendors as a spec and > > leaving them to it - it's largely an invitation to participate more directly > > upstream to help resolve a particularly t

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On Tue, 25 Mar 2014 23:09:45 +1000 Nick Coghlan wrote: > > Alternative: selectively backport particular APIs > - > > An instinctively minimalist reaction to this proposal is to only backport > particular APIs in the affected modules that are judged

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

[Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

Hi, On core-mentorship someone asked about PEP 3145 - Asynchronous I/O for subprocess.popen. I answered that asyncio now has subprocess support (including non-blocking I/O on the three standard stream pipes), so it's not obvious anything else is needed. Should we change the PEP's status to Reje

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

[Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

Urk. Premature send. As it turns out, I had no specific comments to make after the one comment on > Alternative: create and release Python 2.8 > -- My apologies to anybody who read to the bottom for wasting their time. I do have one generic comment on

[Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

Nick Coghlan writes: > Changes to these modules will still need to undergo normal backwards > compatibility assessments to ensure their default behaviour remains > consistent with earlier Python 2.7 releases, I find this wording confusing. Does this mean that (possibly imaginary example) wher

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

Am 25.03.14 14:47, schrieb Nick Coghlan: > The PEP says to sync with Python 3, and that has full cross platform > support. The Linux focus just comes from the fact that Linux is where > the problem is most evident. However, it fails to address a critical detail: the upcoming maintenance end for 2.

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On Mar 25, 2014, at 1:16 PM, Guido van Rossum wrote: > On Tue, Mar 25, 2014 at 9:46 AM, Donald Stufft wrote: > > On Mar 25, 2014, at 12:35 PM, Guido van Rossum wrote: > [...] >> >> I do note that the PEP seems to have some weasel-words about breaking >> backward compatibility in the name of

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On Tue, Mar 25, 2014 at 9:46 AM, Donald Stufft wrote: > > On Mar 25, 2014, at 12:35 PM, Guido van Rossum wrote: > [...] > > I do note that the PEP seems to have some weasel-words about breaking > backward compatibility in the name of security. The phrase "This PEP does > *not* grant Python 2.7 a

Re: [Python-Dev] 3.3 branch is now in security fix mode

Sent from my iPhone ___ 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 (round 4): Python 2.7 network security enhancements

On Mar 25, 2014, at 12:35 PM, Guido van Rossum wrote: > On Tue, Mar 25, 2014 at 8:31 AM, Alex Gaynor wrote: > A casual glance at > https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/ > util.py#L610 > which is probably the most widely used consumer of these APIs, outs

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On Tue, Mar 25, 2014 at 8:31 AM, Alex Gaynor wrote: > A casual glance at > > https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/ > util.py#L610 > which is probably the most widely used consumer of these APIs, outside the > stdlib itself, looks to me like if these names

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

A casual glance at https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/ util.py#L610 which is probably the most widely used consumer of these APIs, outside the stdlib itself, looks to me like if these names were to suddenly show up, everything would continue to work just

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On Tue, Mar 25, 2014 at 8:10 AM, Antoine Pitrou wrote: > The problem with backporting SSLContext is really that 1) you are adding > a non-minimal new API set to the 2.7 feature set; 2) you must make it so > that other stdlib modules take advantage of the new APIs (otherwise > why bother?). > I a

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 (round 4): Python 2.7 network security enhancements

On Tue, 25 Mar 2014 14:25:29 + Paul Moore wrote: > On 25 March 2014 13:47, Nick Coghlan wrote: > > It's not like we're going to just be giving the PEP to vendors as a spec and > > leaving them to it - it's largely an invitation to participate more directly > > upstream to help resolve a parti

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On 25 March 2014 13:47, Nick Coghlan wrote: > It's not like we're going to just be giving the PEP to vendors as a spec and > leaving them to it - it's largely an invitation to participate more directly > upstream to help resolve a particularly thorny problem, not a Statement of > Work :) :-) I d

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On 25 Mar 2014 23:29, "Paul Moore" wrote: > > On 25 March 2014 13:09, Nick Coghlan wrote: > > * MvL has indicated he is not prepared to tackle the task of trying to > > integrate a newer OpenSSL into the also aging Python 2.7 build > > infrastructure on Windows (unfortunately, we've looked in

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On 25 March 2014 13:09, Nick Coghlan wrote: > * MvL has indicated he is not prepared to tackle the task of trying to > integrate a newer OpenSSL into the also aging Python 2.7 build > infrastructure on Windows (unfortunately, we've looked into upgrading > that build infrastructure, and the b

[Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

Hmm, should probably have more entries in the post history... Anyway: * As Ben Darnell noted, the legacy SSL branch thing was a fundamentally bad idea. We can't stop downstream redistributors doing that if they really want to, but we don't have to encourage them * I also explained why I think sele

Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7

On Mar 25, 2014, at 06:11 PM, Nick Coghlan wrote: >I actually agree with this (hence why I wrote the PEP in the first >place), I just became really, really, really, annoyed with certain >organisations over the course of writing the PEP drafts and that is >reflected in the tone of the latest draft.

Re: [Python-Dev] 3.4 buildbots available

Am 22.03.14 22:03, schrieb Benjamin Peterson: > > On Sat, Mar 22, 2014, at 11:10, Antoine Pitrou wrote: >> >> Hello, >> >> I've created the 3.4 category in the buildbots setup: >> http://buildbot.python.org/all/waterfall?category=3.4.stable >> >> I've also retired 3.2 and 3.3 buildbots. Someone wi

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] RFE 20469: ssl.getpeercert() should include extensions

On 24.03.2014 23:51, Andrew M. Hettinger wrote: > I thought I'd wait until the 3.4 release before I bothered asking about > this: http://bugs.python.org/issue20469 > > I don't think I'm qualified to actually be writing code for the ssl > module, but is there anything else that I can do to help? >

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 (round 2): Network security enhancements for Python 2.7

On 25 March 2014 09:04, Donald Stufft wrote: > On Mar 24, 2014, at 5:38 PM, Nick Coghlan wrote: > While I totally agree that it would be incredibly awesome if more companies > put > dedicated time into developing and maintaining CPython I don't think pushing > all the blame on to them is accurate

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