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 their internal
> network security, and hence tolerate (or even actively
On 31 August 2014 12:21, R. David Murray wrote:
> Do those knobs allow one to instruct urllib to accept an invalid
> certificate without changing the program code?
My first reply ended up being a context dump of the challenges created
by legacy corporate intranets that may not be immediately obvi
> 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 their internal
> network security, and hence tolerate (or even actively encourage) the
> use of unsecured connections,
On 31 August 2014 12:21, R. David Murray wrote:
> On Sun, 31 Aug 2014 03:25:25 +0200, Antoine Pitrou
> wrote:
>> On Sun, 31 Aug 2014 09:26:30 +1000
>> Nick Coghlan wrote:
>> > In relation to changing the Python CLI API to offer some of the wget/curl
>> > style command line options, I like the i
mar...@v.loewis.de writes:
> BTW, it's patented:
>
> http://www.google.de/patents/US6816900
Damn them. I hope they never get a look at my crontab.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
On Sun, 31 Aug 2014 03:25:25 +0200, Antoine Pitrou wrote:
> On Sun, 31 Aug 2014 09:26:30 +1000
> Nick Coghlan wrote:
> > >>
> > >> * configuration:
> > >>
> > >> It would be good to be able to switch this on or off
> > >> without having to change the code, e.g. via a command
> > >>
On Sun, 31 Aug 2014 09:26:30 +1000
Nick Coghlan wrote:
> >>
> >> * configuration:
> >>
> >> It would be good to be able to switch this on or off
> >> without having to change the code, e.g. via a command
> >> line switch and environment variable; perhaps even
> >> controlling whe
On 30 Aug 2014 06:08, "Ethan Furman" wrote:
>
> On 08/29/2014 01:00 PM, M.-A. Lemburg wrote:
>>
>> On 29.08.2014 21:47, Alex Gaynor wrote:
>>>
>>>
>>> I've just submitted PEP 476, on enabling certificate validation by
default for
>>> HTTPS clients in Python. Please have a look and let me know what
Zitat von Christian Heimes :
On 30.08.2014 17:22, Alex Gaynor wrote:
The Windows certificate store is used by ``load_default_certs``:
* https://github.com/python/cpython/blob/master/Lib/ssl.py#L379-L381
* https://docs.python.org/3.4/library/ssl.html#ssl.enum_certificates
The Windows part of
On 30.08.2014 17:22, Alex Gaynor wrote:
> The Windows certificate store is used by ``load_default_certs``:
>
> * https://github.com/python/cpython/blob/master/Lib/ssl.py#L379-L381
> * https://docs.python.org/3.4/library/ssl.html#ssl.enum_certificates
The Windows part of load_default_certs() has o
On Aug 30, 2014, at 12:19 PM, M.-A. Lemburg wrote:
>The reasoning here is the same as for hash randomization. There
>are cases where you want to test your application using self-signed
>certificates which don't validate against the system CA root list.
>
>In those cases, you do know what you're do
Paul Moore :
> Cool, in which case this sounds like a good plan. I have no particular
> opinion on whether there should be a global Python-level "don't check
> certificates" option, but I would suggest that the docs include a
> section explaining how a user can implement a
> "--no-check-certificat
On 30 August 2014 16:22, Alex Gaynor wrote:
> The Windows certificate store is used by ``load_default_certs`
Cool, in which case this sounds like a good plan. I have no particular
opinion on whether there should be a global Python-level "don't check
certificates" option, but I would suggest that
The Windows certificate store is used by ``load_default_certs``:
* https://github.com/python/cpython/blob/master/Lib/ssl.py#L379-L381
* https://docs.python.org/3.4/library/ssl.html#ssl.enum_certificates
Cheers, Alex
___
Python-Dev mailing list
Python-D
This sounds great, but the disable switch worries me if it's an ENVVAR=1 kind
of deal. Those switches have a tendency on Windows of becoming "well known
tricks" and they get set globally and permanently, often by application
installers or sysadmins (PYTHONPATH suffers the exact same problem).
I
On 30.08.2014 15:32, R. David Murray wrote:
> On Sat, 30 Aug 2014 14:03:57 +0200, "M.-A. Lemburg" wrote:
>> On 30.08.2014 12:55, Antoine Pitrou wrote:
>>> On Sat, 30 Aug 2014 12:46:47 +0200
>>> "M.-A. Lemburg" wrote:
> That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE
>>>
On Sat, 30 Aug 2014 14:03:57 +0200, "M.-A. Lemburg" wrote:
> On 30.08.2014 12:55, Antoine Pitrou wrote:
> > On Sat, 30 Aug 2014 12:46:47 +0200
> > "M.-A. Lemburg" wrote:
> >>> That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE
> >>> env vars (or, better, by specific settings *
On 30.08.2014 12:55, Antoine Pitrou wrote:
> On Sat, 30 Aug 2014 12:46:47 +0200
> "M.-A. Lemburg" wrote:
>> The change is to the OpenSSL API, not the OpenSSL lib. By setting
>> the variable you enable a few special calls to the config loader
>> functions in OpenSSL when calling the initializer it:
On Sat, 30 Aug 2014 12:46:47 +0200
"M.-A. Lemburg" wrote:
> The change is to the OpenSSL API, not the OpenSSL lib. By setting
> the variable you enable a few special calls to the config loader
> functions in OpenSSL when calling the initializer it:
>
> https://www.openssl.org/docs/crypto/OPENSSL_
30 August 2014 03:44, Alex Gaynor wrote:
> Discussion points:
>
> * Disabling verification entirely externally to the program, through a CLI
> flag
> or environment variable. I'm pretty down on this idea, the problem you hit
> is
> that it's a pretty blunt instrument to swing, and it's almo
On 30.08.2014 12:40, Antoine Pitrou wrote:
> On Sat, 30 Aug 2014 12:19:11 +0200
> "M.-A. Lemburg" wrote:
>>> To add to the PEP:
>>>
>>> * Emit a warning in 3.4.next for cases that would raise a Exception in 3.5
>>> * Clearly state that the existing OpenSSL environment variables will be
>>> respe
On Sat, 30 Aug 2014 12:19:11 +0200
"M.-A. Lemburg" wrote:
> > To add to the PEP:
> >
> > * Emit a warning in 3.4.next for cases that would raise a Exception in 3.5
> > * Clearly state that the existing OpenSSL environment variables will be
> > respected for setting the trust root
>
> I'd also
On 30.08.2014 04:44, Alex Gaynor wrote:
> Thanks for the rapid feedback everyone!
>
> I want to summarize the action items and discussion points that have come up
> so
> far:
>
> To add to the PEP:
>
> * Emit a warning in 3.4.next for cases that would raise a Exception in 3.5
> * Clearly state
On 30.08.2014 01:37, Greg Ewing wrote:
> M.-A. Lemburg wrote:
>> we needed
>> a way to make sure that Python 3 also optionally supports working
>> with lone surrogates in such UTF-8 streams (nowadays called CESU-8:
>> http://en.wikipedia.org/wiki/CESU-8).
>
> I don't think CESU-8 is the same thing
24 matches
Mail list logo
