Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 01.09.2014 08:44, Nick Coghlan wrote: > Yes, it would have exactly the same security failure modes as > sitecustomize, except it would only fire if the application > imported the ssl module. > > The "-S" and "-I" switches would need to disable the implied > "sslcustomize", just as they disabl

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner wrote: Le 1 sept. 2014 00:17, "Marko Rauhamaa" > a écrit : > If a signal is received when read() or write() has completed its task > partially (> 0 bytes), no EINTR is returned but the partial count. > Obviously, Python should take that possibility int

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

No, it's the opposite. The PEP doesn't change the default behaviour of SIGINT: CTRL+C always interrupt the program. Victor Le 1 sept. 2014 08:12, "Paul Moore" a écrit : > On 31 August 2014 22:38, Victor Stinner wrote: > > This case is described as the use case #2 in the PEP, so it is > supporte

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

> On Sep 1, 2014, at 2:22 AM, Ned Deily wrote: > > In article > >, > Nick Coghlan mailto:ncogh...@gmail.com>> wrote: >> On 1 Sep 2014 09:23, "Benjamin Peterson" wrote: >>> On Sun, Aug 31, 2014, at 16:17, Antoine Pitrou

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Le 1 sept. 2014 02:40, "Greg Ewing" a écrit : > > Victor Stinner wrote: >> >> As written in the PEP, if you want to be notified of the signal, set a signal handler which raises an exception. > > > I'm not convinced that this covers all possible use cases. > It might be all right if you have contro

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner : > No, it's the opposite. The PEP doesn't change the default behaviour of > SIGINT: CTRL+C always interrupt the program. Which raises an interesting question: what happens to the os.read() return value if SIGINT is received? Marko ___

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 1 September 2014 17:13, Christian Heimes wrote: > On 01.09.2014 08:44, Nick Coghlan wrote: >> Yes, it would have exactly the same security failure modes as >> sitecustomize, except it would only fire if the application >> imported the ssl module. >> >> The "-S" and "-I" switches would need to d

[Python-Dev] Bug 19494 ... urllib2.HTTPBasicAuthHandler for GitHub et al.

Hi, now when the vacations even in Europe are over could I ask for some movement on http://bugs.python.org/issue19494? Demanding a half-megabyte amount of packages from PIP ('just use requests' mentioned by some comments in the thread) or for that matter any package from PIP (including mine h

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

On 1 Sep 2014 17:31, "Donald Stufft" wrote: > > >> On Sep 1, 2014, at 2:22 AM, Ned Deily wrote: >> >> >> And that is a minor complication compared with the confusion and >> difficulty of trying to explain to users (stuck with 2.7 for the time >> being) of how to install third-party packages on ea

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

There's no return value, a KeywordInterrupt exception is raised. The PEP wouldn't change this behavior. As for the general behavior: all programming languages/platforms handle EINTR transparently. It's high time for Python to have a sensible behavior in this regard. 2014-09-01 8:38 GMT+01:00 Ma

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Charles-François Natali : >> Which raises an interesting question: what happens to the os.read() >> return value if SIGINT is received? > > There's no return value, a KeywordInterrupt exception is raised. > The PEP wouldn't change this behavior. Slightly disconcerting... but I'm sure overriding S

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-09-01 12:15 GMT+01:00 Marko Rauhamaa : > Charles-François Natali : > >>> Which raises an interesting question: what happens to the os.read() >>> return value if SIGINT is received? >> >> There's no return value, a KeywordInterrupt exception is raised. >> The PEP wouldn't change this behavior.

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

Le 01/09/2014 10:09, Nick Coghlan a écrit : > On 1 September 2014 17:13, Christian Heimes wrote: >> On 01.09.2014 08:44, Nick Coghlan wrote: >>> Yes, it would have exactly the same security failure modes as >>> sitecustomize, except it would only fire if the application >>> imported the ssl module

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 19:15:33 +1200 Greg Ewing wrote: > Victor Stinner wrote: > > > > Le 1 sept. 2014 00:17, "Marko Rauhamaa" > > a écrit : > > > If a signal is received when read() or write() has completed its task > > > partially (> 0 bytes), no EINTR is returned but

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Hi, I'm +1 on the whole PEP. > Writing a signal handler is difficult, only "async-signal safe" > functions can be called. You mean a C signal handler? Python signal handlers are not restricted. > Some signals are not interesting and should not interrupt the the > application. There are two op

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Mon, Sep 1, 2014 at 10:41 PM, Antoine Pitrou wrote: > Not sure why. Just put another module named "ssl" in sys.modules directly. > You can also monkeypatch the genuine ssl module. That has to be done inside the same process. But imagine this scenario: You have a program that gets invoked as ro

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Mon, 1 Sep 2014 23:24:39 +1000 Chris Angelico wrote: > On Mon, Sep 1, 2014 at 10:41 PM, Antoine Pitrou wrote: > > Not sure why. Just put another module named "ssl" in sys.modules directly. > > You can also monkeypatch the genuine ssl module. > > That has to be done inside the same process. Bu

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Mon, Sep 1, 2014 at 11:34 PM, Antoine Pitrou wrote: > On Mon, 1 Sep 2014 23:24:39 +1000 > Chris Angelico wrote: >> On Mon, Sep 1, 2014 at 10:41 PM, Antoine Pitrou wrote: >> > Not sure why. Just put another module named "ssl" in sys.modules directly. >> > You can also monkeypatch the genuine s

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Mon, 1 Sep 2014 23:42:10 +1000 Chris Angelico wrote: > On Mon, Sep 1, 2014 at 11:34 PM, Antoine Pitrou wrote: > > On Mon, 1 Sep 2014 23:24:39 +1000 > > Chris Angelico wrote: > >> On Mon, Sep 1, 2014 at 10:41 PM, Antoine Pitrou wrote: > >> > Not sure why. Just put another module named "ssl" i

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 2 Sep 2014 00:08, "Antoine Pitrou" wrote: > > On Mon, 1 Sep 2014 23:42:10 +1000 > Chris Angelico wrote: > > >> > > >> That has to be done inside the same process. But imagine this > > >> scenario: You have a program that gets invoked as root (or some other > > >> user than yourself), and you'r

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Tue, 2 Sep 2014 00:53:11 +1000 Nick Coghlan wrote: > On 2 Sep 2014 00:08, "Antoine Pitrou" wrote: > > > > On Mon, 1 Sep 2014 23:42:10 +1000 > > Chris Angelico wrote: > > > >> > > > >> That has to be done inside the same process. But imagine this > > > >> scenario: You have a program that gets

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 2 Sep 2014 00:59, "Antoine Pitrou" wrote: > > On Tue, 2 Sep 2014 00:53:11 +1000 > Nick Coghlan wrote: > > > > > > To be frank I don't understand what you're arguing about. > > > > When I said "shadowing ssl can be tricky to arrange", Chris correctly > > interpreted it as referring to the files

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 08:30:27 +0300, Marko Rauhamaa wrote: > "R. David Murray" : > > > PS: I recently switched from using selectors to using a timeout on a > > socket because in that particular application I could, and because > > reading a socket with a timeout handles EINTR (in recent python > >

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 14:15:52 +0300, Marko Rauhamaa wrote: > Charles-François Natali : > > >> Which raises an interesting question: what happens to the os.read() > >> return value if SIGINT is received? > > > > There's no return value, a KeywordInterrupt exception is raised. > > The PEP wouldn't

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 11:47:07 -0400 "R. David Murray" wrote: > > > > The two requirements are: > > > > * Allow the application to react to signals immediately in the main > >flow. > > You don't want to be writing your code in Python then. In Python > you *never* get to react immediately to

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

"R. David Murray" : > Windows. Enough said? > [...] > This should tell you just about everything you need to know about why > we want to fix this problem so that things work cross platform. I feel your pain. Well, not really; I just don't want my linux bliss to be taken away. Marko ___

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

"R. David Murray" : > On Mon, 01 Sep 2014 14:15:52 +0300, Marko Rauhamaa wrote: >> * Allow the application to react to signals immediately in the main >>flow. > > You don't want to be writing your code in Python then. In Python you > *never* get to react immediately to signals. The interpret

[Python-Dev] cpython and parallel make

Hi, what’s people’s experience with compiling cpython using multiple jobs (e.g., make -j 8)? In my case, I sometimes experience build errors that happen when using -j, whereas the single-job build always works. I haven’t tracked this down in detail, though… here’s an extract from a sample log: 1

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

> On Sep 1, 2014, at 11:35 AM, Nick Coghlan wrote: > > > On 2 Sep 2014 00:59, "Antoine Pitrou" > wrote: > > > > On Tue, 2 Sep 2014 00:53:11 +1000 > > Nick Coghlan mailto:ncogh...@gmail.com>> wrote: > > > > > > > > To be frank I don't understand what you're arguing a

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 01.09.2014 17:35, Nick Coghlan wrote: > Oh, now I get what you mean - yes, sitecustomize already poses the same > kind of problem as the proposed sslcustomize (hence the existence of the > related command line options). If an attacker is able to place a module like sitecustomize.py in an import

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

> On Sep 1, 2014, at 1:01 PM, Christian Heimes wrote: > > On 01.09.2014 17:35, Nick Coghlan wrote: >> Oh, now I get what you mean - yes, sitecustomize already poses the same >> kind of problem as the proposed sslcustomize (hence the existence of the >> related command line options). > > If an a

Re: [Python-Dev] cpython and parallel make

Hi, My bashrc sets MAKEFLAGS to -j9 and Python compilation works fine on Fedora 20 with GNU make and GCC. My computer has 8 cores (4 physical with hyper threading). It looks like your compiler is Clang. What is your OS and OS version? Can you try to run make in verbose mode and attach the full l

Re: [Python-Dev] cpython and parallel make

On Mon, Sep 1, 2014, 15:16 Victor Stinner wrote: Hi, My bashrc sets MAKEFLAGS to -j9 and Python compilation works fine on Fedora 20 with GNU make and GCC. My computer has 8 cores (4 physical with hyper threading). It looks like your compiler is Clang. What is your OS and OS version? I compil

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner wrote: > HTML version: > http://legacy.python.org/dev/peps/pep-0475/ > PEP: 475 > Title: Retry system calls failing with EINTR I think the proposed design for how Python should behave is a good one. But I think this proposal needs to be treated in the same way as any other backw

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 2 Sep 2014 03:08, "Donald Stufft" wrote: > > >> On Sep 1, 2014, at 1:01 PM, Christian Heimes wrote: >> >> On 01.09.2014 17:35, Nick Coghlan wrote: >>> >>> Oh, now I get what you mean - yes, sitecustomize already poses the same >>> kind of problem as the proposed sslcustomize (hence the existen

Re: [Python-Dev] Daily reference leaks (640c575ab3e1): sum=151940

Is anyone working on those? On Mon, 01 Sep 2014 10:41:45 +0200 solip...@pitrou.net wrote: > results for 640c575ab3e1 on branch "default" > > > test_codecs leaked [5825, 5825, 5825] references, sum=17475 > test_codecs leaked [1172, 1174, 1174] memory

Re: [Python-Dev] Daily reference leaks (640c575ab3e1): sum=151940

The codecs one is https://bugs.python.org/issue22166 On Mon, Sep 1, 2014, at 16:16, Antoine Pitrou wrote: > > Is anyone working on those? > > > > On Mon, 01 Sep 2014 10:41:45 +0200 > solip...@pitrou.net wrote: > > results for 640c575ab3e1 on branch "default" > > ---

Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)

As of today I still am getting untrusted cert thought I would re-ping to see if there is an ETA. On Thu, Aug 21, 2014 at 10:32 PM, Terry Reedy wrote: > On 8/21/2014 7:25 PM, Nick Coghlan wrote: > >> >> On 22 Aug 2014 04:45, "Benjamin Peterson" > > wrote: >> > >> > P

Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)

I got the same in Chrome on my Mac. Skip On Sep 1, 2014 8:00 PM, "John Wong" wrote: > As of today I still am getting untrusted cert thought I would re-ping to > see if there is an ETA. > > On Thu, Aug 21, 2014 at 10:32 PM, Terry Reedy wrote: > >> On 8/21/2014 7:25 PM, Nick Coghlan wrote: >> >>>

Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)

Hi! On Mon, Sep 01, 2014 at 08:32:27PM -0500, Skip Montanaro wrote: > I got the same in Chrome on my Mac. > > Skip > On Sep 1, 2014 8:00 PM, "John Wong" wrote: > > > As of today I still am getting untrusted cert thought I would re-ping to > > see if there is an ETA. The signing certificat