On 1 September 2014 16:07, Paul Moore wrote:
> On 31 August 2014 23:10, Nick Coghlan wrote:
>> Assuming sslcustomize was in site-packages rather than the standard library
>> directories, you would also be able to use virtual environments with an
>> appropriate sslcustomize module to disable cert
In article
,
Nick Coghlan wrote:
> On 1 Sep 2014 09:23, "Benjamin Peterson" wrote:
> > On Sun, Aug 31, 2014, at 16:17, Antoine Pitrou wrote:
> > > On Mon, 1 Sep 2014 08:00:14 +1000
> > > Nick Coghlan wrote:
> > > >
> > > > That part of the proposal proved to be controversial, so we dropped
> i
On 31 August 2014 22:38, Victor Stinner wrote:
> This case is described as the use case #2 in the PEP, so it is supported. As
> written in the PEP, if you want to be notified of the signal, set a signal
> handler which raises an exception. For example the default signal handler
> for SIGINT raises
On 31 August 2014 23:10, Nick Coghlan wrote:
> Assuming sslcustomize was in site-packages rather than the standard library
> directories, you would also be able to use virtual environments with an
> appropriate sslcustomize module to disable cert checking even if the
> application you were running
On 1 September 2014 11:10, R. David Murray wrote:
>
> It sounds like this would address my concerns as well (I don't really
> care *how* it is implemented as long as I don't have to touch the
> code of a third party application when I upgrade my python version to
> 3.5...remember, the context here
"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
> versions), whereas reading a non-blocking socket doesn't. Under the
>
On Sun, 31 Aug 2014 20:14:50 -0700, Dan Stromberg wrote:
> On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing
> wrote:
> > 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
On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing wrote:
> 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 co
On Mon, 01 Sep 2014 08:10:58 +1000, Nick Coghlan wrote:
> On 1 Sep 2014 07:43, "Christian Heimes" wrote:
> >
> > On 31.08.2014 08:09, Nick Coghlan wrote:
> > > As Antoine says here, I'm also opposed to adding more Python specific
> > > configuration options. However, I think there may be somethin
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 control over the signal
handler, but what if you don't?
I think it
On 1 Sep 2014 08:15, "Donald Stufft" wrote:
>
>
>> On Aug 31, 2014, at 5:43 PM, Christian Heimes
wrote:
>>
>> Companies could install them in a system global directory on their
>> servers. Users could put them in their own user site directory and even
>> each virtual env can have one sslcustomize
On 1 Sep 2014 09:23, "Benjamin Peterson" wrote:
>
> On Sun, Aug 31, 2014, at 16:17, Antoine Pitrou wrote:
> > On Mon, 1 Sep 2014 08:00:14 +1000
> > Nick Coghlan wrote:
> > >
> > > That part of the proposal proved to be controversial, so we dropped
it from
> > > the original PEP in order to focus
On Sun, Aug 31, 2014, at 16:17, Antoine Pitrou wrote:
> On Mon, 1 Sep 2014 08:00:14 +1000
> Nick Coghlan wrote:
> >
> > That part of the proposal proved to be controversial, so we dropped it from
> > the original PEP in order to focus on meeting the Python 3.4 specific
> > release deadlines. This
On Mon, 1 Sep 2014 08:00:14 +1000
Nick Coghlan wrote:
>
> That part of the proposal proved to be controversial, so we dropped it from
> the original PEP in order to focus on meeting the Python 3.4 specific
> release deadlines. This also had the benefit of working out the kinks in
> the bootstrapp
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 into account so that
> raising an exception in the signal
On 8/31/2014 6:00 PM, Nick Coghlan wrote:
Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7
maintenance release in addition to including it with Python 3.4.
That part of the proposal proved to be controversial, so we dropped it
from the original PEP in order to focus on me
On Mon, 01 Sep 2014 01:15:12 +0300
Marko Rauhamaa wrote:
>
> 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 into account so that
> raising an exception in t
Le 1 sept. 2014 00:04, "Marko Rauhamaa" a écrit :
>
> Victor Stinner :
>
> > But I don't get you point. How does this PEP make the situation worse?
>
> Did I say it would? I just wanted to make sure the system call
> resumption doesn't become mandatory.
The syscall is only retried on EINTR if the
> On Aug 31, 2014, at 5:43 PM, Christian Heimes wrote:
>
> On 31.08.2014 08:09, Nick Coghlan wrote:
>> As Antoine says here, I'm also opposed to adding more Python specific
>> configuration options. However, I think there may be something
>> worthwhile we can do that's closer to the way browsers
Ethan Furman :
> On 08/31/2014 02:19 PM, Marko Rauhamaa wrote:
>> The application will often want the EINTR return (exception) instead
>> of having the function resume on its own.
>
> Examples?
>
> As an ignorant person in this area, I do not know why I would ever
> want to have EINTR raised inste
On 1 Sep 2014 07:43, "Christian Heimes" wrote:
>
> On 31.08.2014 08:09, Nick Coghlan wrote:
> > As Antoine says here, I'm also opposed to adding more Python specific
> > configuration options. However, I think there may be something
> > worthwhile we can do that's closer to the way browsers work,
Victor Stinner :
> But I don't get you point. How does this PEP make the situation worse?
Did I say it would? I just wanted to make sure the system call
resumption doesn't become mandatory.
Haven't thought through what the exception raising technique would
entail. It might be perfectly ok apart
On 31.08.2014 22:30, Paul Moore wrote:
> On 31 August 2014 21:15, Antoine Pitrou wrote:
>> What do you call your local cert store?
>
> I was referring to Christian's comment
>> It's very simple to trust a self-signed certificate: just download it and
>> stuff it into the trust store.
I was refe
Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7
maintenance release in addition to including it with Python 3.4.
That part of the proposal proved to be controversial, so we dropped it from
the original PEP in order to focus on meeting the Python 3.4 specific
release deadli
Le 31/08/2014 23:41, Nick Coghlan a écrit :
Right, this is why I came to the conclusion we need to follow the browser
vendors lead here and support a per-user Python specific supplementary
certificate cache before we can start validating certs by default at the
*Python* level. There are still too
On 31.08.2014 08:09, Nick Coghlan wrote:
> As Antoine says here, I'm also opposed to adding more Python specific
> configuration options. However, I think there may be something
> worthwhile we can do that's closer to the way browsers work, and has
> the significant benefit of being implementable a
On 1 Sep 2014 06:32, "Paul Moore" wrote:
>
> On 31 August 2014 21:15, Antoine Pitrou wrote:
> > What do you call your local cert store?
>
> I was referring to Christian's comment
> > It's very simple to trust a self-signed certificate: just download it
and stuff it into the trust store.
>
> From
Le dimanche 31 août 2014, Marko Rauhamaa a écrit :
> Victor Stinner >:
>
> > Sorry but I don't understand your remark. What is your problem with
> > retrying syscall on EINTR?
>
> The application will often want the EINTR return (exception) instead of
> having the function resume on its own.
Th
On 08/31/2014 02:19 PM, Marko Rauhamaa wrote:
Victor Stinner :
Sorry but I don't understand your remark. What is your problem with
retrying syscall on EINTR?
The application will often want the EINTR return (exception) instead of
having the function resume on its own.
Examples?
As an ignor
Victor Stinner :
> Sorry but I don't understand your remark. What is your problem with
> retrying syscall on EINTR?
The application will often want the EINTR return (exception) instead of
having the function resume on its own.
> Can you please elaborate? What do you mean by "get wrong"?
Proper
Hi,
Sorry but I don't understand your remark. What is your problem with
retrying syscall on EINTR? Can you please elaborate? What do you mean by
"get wrong"?
Victor
Le dimanche 31 août 2014, Marko Rauhamaa a écrit :
> Victor Stinner >:
>
> > Proposition
> > ===
> >
> > If a system call
On 31 August 2014 21:15, Antoine Pitrou wrote:
> What do you call your local cert store?
I was referring to Christian's comment
> It's very simple to trust a self-signed certificate: just download it and
> stuff it into the trust store.
>From his recent response, I guess he meant the system sto
On 31.08.2014 19:29, Antoine Pitrou wrote:
> You certainly shouldn't do so. If an application has special needs that
> require trusting a self-signed certificate, then it should expose a
> configuration setting to let users specify the cert's location. Stuffing
> self-signed certs into the system t
Le 31/08/2014 21:12, Paul Moore a écrit :
On 31 August 2014 19:37, Antoine Pitrou wrote:
Well, it's certainly pip's responsibility more than Python's. What would
Python do? Provide a setting that would blindly add a cert for all uses of
httplib?
That's more or less my point, pip doesn't have
On 31 August 2014 19:37, Antoine Pitrou wrote:
> Well, it's certainly pip's responsibility more than Python's. What would
> Python do? Provide a setting that would blindly add a cert for all uses of
> httplib?
That's more or less my point, pip doesn't have that much better idea
than Python. I was
Le 31/08/2014 20:28, Paul Moore a écrit :
I can't see how that would be something the application would know.
For example, pip allows me to specify an "alternate cert bundle" but
not a single additional cert. So IIUC, I can't use my local index that
serves https using a self-signed cert. I'd fin
On 31 August 2014 18:29, Antoine Pitrou wrote:
> If an application has special needs that require trusting a self-signed
> certificate, then it should expose a configuration setting to let users
> specify the cert's location.
I can't see how that would be something the application would know.
For
Le 31/08/2014 19:03, Paul Moore a écrit :
On 31 August 2014 17:27, Christian Heimes wrote:
It's very simple to trust a self-signed certificate: just download it
and stuff it into the trust store.
"Stuff it into the trust store" is the hard bit, though. I have
honestly no idea how to do that.
On 31.08.2014 08:24, Nick Coghlan wrote:
> To answer David's specific question, the existing knobs at the OpenSSL
> level (SSL_CERT_DIR and SSL_CERT_FILE ) let people add an internal CA,
> opt out of the default CA system, and trust *specific* self-signed
> certs.
This works only on Unix platforms
On 31 August 2014 17:27, Christian Heimes wrote:
> It's very simple to trust a self-signed certificate: just download it
> and stuff it into the trust store.
"Stuff it into the trust store" is the hard bit, though. I have
honestly no idea how to do that. Or if it's temporary (which it likely
is)
On 31.08.2014 16:16, R. David Murray wrote:
> Self -signed certificates are not crazy in an internal corporate
> environment even when properly playing the defense in depth game. Once
> you've acked the cert the first time, you will be warned if it changes
> (like an ssh host key). Sure, as Nick
Victor Stinner :
> Proposition
> ===
>
> If a system call fails with ``EINTR``, Python must call signal
> handlers: call ``PyErr_CheckSignals()``. If a signal handler raises
> an exception, the Python function fails with the exception.
> Otherwise, the system call is retried. If the syste
Hi,
I've released mpdecimal-2.4.1:
http://www.bytereef.org/mpdecimal/changelog.html
da74d3cfab559971a4fbd4fb506e1b4498636eb77d0fd09e44f8e546d18ac068
mpdecimal-2.4.1.tar.gz
Starting with Python 3.4.2, this version should be used for an external
libmpdec.
Stefan Krah
On Sun, 31 Aug 2014 16:45:42 +1000, Nick Coghlan wrote:
> On 31 August 2014 16:16, Donald Stufft wrote:
> >
> > On Aug 31, 2014, at 2:09 AM, Nick Coghlan wrote:
> >
> > At the same time, we need to account for the fact that most existing
> > organisations still trust in perimeter defence for the
HTML version:
http://legacy.python.org/dev/peps/pep-0475/
PEP: 475
Title: Retry system calls failing with EINTR
Version: $Revision$
Last-Modified: $Date$
Author: Charles-François Natali , Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 29-July-2014
Python-Vers
On 30.08.2014 00:22, Antoine Pitrou wrote:
> SSL_CERT_DIR and SSL_CERT_FILE are used, if set, when
> SSLContext.load_verify_locations() is called.
>
> Actually, come to think of it, this allows us to write a better
> test for that method. Patch welcome!
The environment vars are used only when
SSL
On 31 August 2014 07:45, Nick Coghlan wrote:
> There's also the fact that most corporate Python users are
> unlikely to know that PyPI exists, let alone that it contains a module
> called "requests" that does SSL certificate validation by default.
> Those of us in the corporate world that interact
47 matches
Mail list logo
