Re: [Python-Dev] surrogatepass - she's a witch, burn 'er! [was: Cleaning up ...]
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. According to the wiki page, CESU-8 *requires* all code points above 0x to be split into surrogate pairs before encoding. It also doesn't say that lone surrogates are valid -- it doesn't mention lone surrogates at all, only pairs. Neither does the linked technical report. The technical report also says that CESU-8 forbids any UTF-8 sequences of more than three bytes, so it's definitely not UTF-8 plus lone surrogates. You're right, it's not the same as UTF-8 plus lone surrogates. CESU-8 does encode surrogates as individual code points using the UTF-8 encoding, which is what probably caused it to be mentioned in discussions when talking about having UTF-8 streams do the same for lone surrogates. So let's call the encoding UTF-8-py so that everyone knows what we're talking about :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 30 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-08-27: Released eGenix PyRun 2.0.1 ... http://egenix.com/go62 2014-09-19: PyCon UK 2014, Coventry, UK ...20 days to go 2014-09-27: PyDDF Sprint 2014 ... 28 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 476: Enabling certificate validation by default!
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 that the existing OpenSSL environment variables will be respected for setting the trust root I'd also suggest to compile Python with OPENSSL_LOAD_CONF, since that causes OpenSSL to read the global openssl.cnf file for additional configuration. 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 almost impossible to imagine it not hitting things it shouldn't; it's far too likely to be used in applications that make two sets of outbound connections: 1) to some internal service which you want to disable verification on, and 2) some external service which needs strong validation. A global flag causes the latter to fail silently when subjected to a MITM attack, and that's exactly what we're trying to avoid. It also makes things much harder for library authors: I write an API client for some API, and make TLS connections to it. I want those to be verified by default. I can't even rely on the httplib defaults, because someone might disable them from the outside. 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 doing. The test would fail otherwise and the reason is not a bug in your code, it's just the fact that the environment you're running it in is a test environment. Ideally, all applications should give you this choice, but this is unlikely to happen, so it's good to be able to change the Python default, since with the proposed change, most applications will probably continue to use the Python defaults as they do now. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 30 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-08-27: Released eGenix PyRun 2.0.1 ... http://egenix.com/go62 2014-09-19: PyCon UK 2014, Coventry, UK ...20 days to go 2014-09-27: PyDDF Sprint 2014 ... 28 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 476: Enabling certificate validation by default!
On Sat, 30 Aug 2014 12:19:11 +0200 M.-A. Lemburg m...@egenix.com 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 suggest to compile Python with OPENSSL_LOAD_CONF, since that causes OpenSSL to read the global openssl.cnf file for additional configuration. Python links against OpenSSL as a shared library, not statically. It's unlikely that setting a compile constant inside Python would affect OpenSSL at all. 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 almost impossible to imagine it not hitting things it shouldn't; it's far too likely to be used in applications that make two sets of outbound connections: 1) to some internal service which you want to disable verification on, and 2) some external service which needs strong validation. A global flag causes the latter to fail silently when subjected to a MITM attack, and that's exactly what we're trying to avoid. It also makes things much harder for library authors: I write an API client for some API, and make TLS connections to it. I want those to be verified by default. I can't even rely on the httplib defaults, because someone might disable them from the outside. 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. That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE env vars (or, better, by specific settings *inside* the application). I'm against multiplying environment variables, as it makes it more difficult to assess the actual security of a setting. The danger of an ill-secure setting is much more severe than with hash randomization. Regards Antoine. ___ 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 476: Enabling certificate validation by default!
On 30.08.2014 12:40, Antoine Pitrou wrote: On Sat, 30 Aug 2014 12:19:11 +0200 M.-A. Lemburg m...@egenix.com 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 suggest to compile Python with OPENSSL_LOAD_CONF, since that causes OpenSSL to read the global openssl.cnf file for additional configuration. Python links against OpenSSL as a shared library, not statically. It's unlikely that setting a compile constant inside Python would affect OpenSSL at all. 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_config.html 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 almost impossible to imagine it not hitting things it shouldn't; it's far too likely to be used in applications that make two sets of outbound connections: 1) to some internal service which you want to disable verification on, and 2) some external service which needs strong validation. A global flag causes the latter to fail silently when subjected to a MITM attack, and that's exactly what we're trying to avoid. It also makes things much harder for library authors: I write an API client for some API, and make TLS connections to it. I want those to be verified by default. I can't even rely on the httplib defaults, because someone might disable them from the outside. 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. That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE env vars (or, better, by specific settings *inside* the application). I'm against multiplying environment variables, as it makes it more difficult to assess the actual security of a setting. The danger of an ill-secure setting is much more severe than with hash randomization. You have a point there. So how about just a python run-time switch and no env var ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 30 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-08-27: Released eGenix PyRun 2.0.1 ... http://egenix.com/go62 2014-09-19: PyCon UK 2014, Coventry, UK ...20 days to go 2014-09-27: PyDDF Sprint 2014 ... 28 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 476: Enabling certificate validation by default!
30 August 2014 03:44, Alex Gaynor alex.gay...@gmail.com 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 almost impossible to imagine it not hitting things it shouldn't As a data point, I use --no-check-certificates extensively, in wget, curl and some Python programs which have it, like youtube-dl. The reason I do so is typically because the programs do not use the Windows cerificate store, and configuring a second certificate store on a per-program basis is too much of a pain to be worth it (per-program because the hacks such programs use to get round the fact that Windows has no central location like /etc are inconsistent). The key question for me is therefore, does Python's ssl support use the Windows store directly these days? I checked the docs and couldn't find anything explicitly stating this (but all the terminology is foreign to me, so I may have missed it). If it does, programs like youtube-dl will start to just work and I won't have the need for a switch off everything flag. If a new Python 3.5 installation on a Windows machine will enforce https cert checking and yet will not check the system store (or, I guess, come with an embedded store, but aren't there maintenance issues with doing that?) then I believe a global don't check flag will be needed, as not all programs offer a don't check certificates mode. And naive users like me may not even know how to code the behaviour for such an option - and the tone of the debate here leads me to believe that it'll be hard for developers to get unbiased advice on how to switch off checking, so it'll end up being patchily implemented. Paul ___ 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 476: Enabling certificate validation by default!
On Sat, 30 Aug 2014 12:46:47 +0200 M.-A. Lemburg m...@egenix.com 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_config.html Ah, ok. Do you have experience with openssl.cnf? Apparently, it is meant for offline tools such as certificate generation, I am not sure how it could impact certification validation. That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE env vars (or, better, by specific settings *inside* the application). I'm against multiplying environment variables, as it makes it more difficult to assess the actual security of a setting. The danger of an ill-secure setting is much more severe than with hash randomization. You have a point there. So how about just a python run-time switch and no env var ? Well, why not, but does it have a value over letting the code properly configure their SSLContext? Regards Antoine. ___ 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 476: Enabling certificate validation by default!
On 30.08.2014 12:55, Antoine Pitrou wrote: On Sat, 30 Aug 2014 12:46:47 +0200 M.-A. Lemburg m...@egenix.com 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_config.html Ah, ok. Do you have experience with openssl.cnf? Apparently, it is meant for offline tools such as certificate generation, I am not sure how it could impact certification validation. I'm still exploring this: the OpenSSL documentation is, well, less than complete on these things, so searching mailing lists and reading source code appears to be the only reasonable way to figure out what is possible and what not. The openssl.cnf config file is indeed mostly used by the various openssl subcommands (e.g. req and ca), but it can also be used to configuring engines and my hope is that configuration of e.g. default certificate stores also becomes possible. One of the engines can tap into the Windows certificate store, for example. That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE env vars (or, better, by specific settings *inside* the application). I'm against multiplying environment variables, as it makes it more difficult to assess the actual security of a setting. The danger of an ill-secure setting is much more severe than with hash randomization. You have a point there. So how about just a python run-time switch and no env var ? Well, why not, but does it have a value over letting the code properly configure their SSLContext? Yes, because when Python changes the default to be validating and more secure, application developers will do the same as they do now: simply use the defaults ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 30 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-08-27: Released eGenix PyRun 2.0.1 ... http://egenix.com/go62 2014-09-19: PyCon UK 2014, Coventry, UK ...20 days to go 2014-09-27: PyDDF Sprint 2014 ... 28 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 476: Enabling certificate validation by default!
On Sat, 30 Aug 2014 14:03:57 +0200, M.-A. Lemburg m...@egenix.com wrote: On 30.08.2014 12:55, Antoine Pitrou wrote: On Sat, 30 Aug 2014 12:46:47 +0200 M.-A. Lemburg m...@egenix.com wrote: That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE env vars (or, better, by specific settings *inside* the application). I'm against multiplying environment variables, as it makes it more difficult to assess the actual security of a setting. The danger of an ill-secure setting is much more severe than with hash randomization. You have a point there. So how about just a python run-time switch and no env var ? Well, why not, but does it have a value over letting the code properly configure their SSLContext? Yes, because when Python changes the default to be validating and more secure, application developers will do the same as they do now: simply use the defaults ;-) But neither of those addresses the articulated use case: someone *using* a program implemented in python that does not itself provide a way to disable the new default security (because it is *new*). Only an environment variable will do that. Since the environment variable is opt-in, I think the consenting adults argument applies to Alex's demure about multiple connections. It could still emit the warnings. --David ___ 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 476: Enabling certificate validation by default!
On 30.08.2014 15:32, R. David Murray wrote: On Sat, 30 Aug 2014 14:03:57 +0200, M.-A. Lemburg m...@egenix.com wrote: On 30.08.2014 12:55, Antoine Pitrou wrote: On Sat, 30 Aug 2014 12:46:47 +0200 M.-A. Lemburg m...@egenix.com wrote: That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE env vars (or, better, by specific settings *inside* the application). I'm against multiplying environment variables, as it makes it more difficult to assess the actual security of a setting. The danger of an ill-secure setting is much more severe than with hash randomization. You have a point there. So how about just a python run-time switch and no env var ? Well, why not, but does it have a value over letting the code properly configure their SSLContext? Yes, because when Python changes the default to be validating and more secure, application developers will do the same as they do now: simply use the defaults ;-) But neither of those addresses the articulated use case: someone *using* a program implemented in python that does not itself provide a way to disable the new default security (because it is *new*). Only an environment variable will do that. Since the environment variable is opt-in, I think the consenting adults argument applies to Alex's demure about multiple connections. It could still emit the warnings. That would be a possibility as well, yes. I'd just like to see a way to say: I know what I'm doing and I'm not in the mood to configure my own CA list, so please go ahead and accept whatever certs you find -- much like what --no-check-certificate does for wget. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 30 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-08-27: Released eGenix PyRun 2.0.1 ... http://egenix.com/go62 2014-09-19: PyCon UK 2014, Coventry, UK ...20 days to go 2014-09-27: PyDDF Sprint 2014 ... 28 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 476: Enabling certificate validation by default!
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). It sounds like the likely approach is a certificate name, which is fine, provided there's no option for accept everything. I just wanted to get an early vote in against a boolean switch. Cheers, Steve Top-posted from my Windows Phone From: R. David Murraymailto:rdmur...@bitdance.com Sent: 8/30/2014 6:33 To: python-dev@python.orgmailto:python-dev@python.org Subject: Re: [Python-Dev] PEP 476: Enabling certificate validation by default! On Sat, 30 Aug 2014 14:03:57 +0200, M.-A. Lemburg m...@egenix.com wrote: On 30.08.2014 12:55, Antoine Pitrou wrote: On Sat, 30 Aug 2014 12:46:47 +0200 M.-A. Lemburg m...@egenix.com wrote: That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE env vars (or, better, by specific settings *inside* the application). I'm against multiplying environment variables, as it makes it more difficult to assess the actual security of a setting. The danger of an ill-secure setting is much more severe than with hash randomization. You have a point there. So how about just a python run-time switch and no env var ? Well, why not, but does it have a value over letting the code properly configure their SSLContext? Yes, because when Python changes the default to be validating and more secure, application developers will do the same as they do now: simply use the defaults ;-) But neither of those addresses the articulated use case: someone *using* a program implemented in python that does not itself provide a way to disable the new default security (because it is *new*). Only an environment variable will do that. Since the environment variable is opt-in, I think the consenting adults argument applies to Alex's demure about multiple connections. It could still emit the warnings. --David ___ 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/steve.dower%40microsoft.com ___ 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 476: Enabling certificate validation by default!
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-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 476: Enabling certificate validation by default!
On 30 August 2014 16:22, Alex Gaynor alex.gay...@gmail.com 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 docs include a section explaining how a user can implement a --no-check-certificates flag in their program if they want to (with appropriate warnings as to the risks, of course!). Better to explain how to do it properly than to say you shouldn't do that and have developers implement awkward or incorrect hacks in spite of the advice. Paul ___ 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 476: Enabling certificate validation by default!
Paul Moore p.f.mo...@gmail.com: 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-certificates flag in their program if they want to (with appropriate warnings as to the risks, of course!). Better to explain how to do it properly than to say you shouldn't do that and have developers implement awkward or incorrect hacks in spite of the advice. Will there be a way to specify a particular CA certificate (as in wget --ca-certificate)? Will there be a way to specify a particular CA certificate directory (as in wget --ca-directory)? Marko ___ 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 476: Enabling certificate validation by default!
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 doing. The test would fail otherwise and the reason is not a bug in your code, it's just the fact that the environment you're running it in is a test environment. Exactly. I have test cases where I have to load up a self-signed cert via .load_cert_chain() and in the good-path tests, I expect to make successful https connections. I also have test cases that expect to fail when: * I load bogus self-signed certs * I have an http server masquerading as an https server * I load an expired self-signed cert It certainly makes sense for the default to be the most secure, but other use cases must be preserved. Cheers, -Barry ___ 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 476: Enabling certificate validation by default!
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 one major flaw: it can only load certificates that are already in Windows's cert store. However Windows comes only with a small set of default certs and downloads more certs on demand. In order to trigger a download Python or OpenSSL would have to use the Windows API to verify root certificates. Christian ___ 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 476: Enabling certificate validation by default!
Zitat von Christian Heimes christ...@python.org: 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 one major flaw: it can only load certificates that are already in Windows's cert store. However Windows comes only with a small set of default certs and downloads more certs on demand. In order to trigger a download Python or OpenSSL would have to use the Windows API to verify root certificates. It's better than you think. Vista+ has a weekly prefetching procedure that should assure that virtually all root certificates are available: http://support.microsoft.com/kb/931125/en-us BTW, it's patented: http://www.google.de/patents/US6816900 Regards, Martin ___ 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 476: Enabling certificate validation by default!
On 30 Aug 2014 06:08, Ethan Furman et...@stoneleaf.us 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 you think. Thanks for the PEP. I think this is generally a good idea, but some important parts are missing from the PEP: * transition plan: I think starting with warnings in Python 3.5 and going for exceptions in 3.6 would make a good transition Going straight for exceptions in 3.5 is not in line with our normal procedures for backwards incompatible changes. * 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 whether or not to raise an exception or warning. * choice of trusted certificate: Instead of hard wiring using the system CA roots into Python it would be good to just make this default and permit the user to point Python to a different set of CA roots. This would enable using self signed certs more easily. Since these are often used for tests, demos and education, I think it's important to allow having more control of the trusted certs. +1 for PEP with above changes. Ditto from me. In relation to changing the Python CLI API to offer some of the wget/curl style command line options, I like the idea of providing recipes in the docs for implementing them at the application layer, but postponing making the *default* behaviour configurable that way. Longer term, I'd like to actually have a per-runtime configuration file for some of these things that also integrated with the pyvenv support, but that requires untangling the current startup code first (and there are only so many hours in the day). Regards, Nick. -- ~Ethan~ ___ 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/ncoghlan%40gmail.com ___ 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 476: Enabling certificate validation by default!
On Sun, 31 Aug 2014 09:26:30 +1000 Nick Coghlan ncogh...@gmail.com 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 whether or not to raise an exception or warning. * choice of trusted certificate: Instead of hard wiring using the system CA roots into Python it would be good to just make this default and permit the user to point Python to a different set of CA roots. This would enable using self signed certs more easily. Since these are often used for tests, demos and education, I think it's important to allow having more control of the trusted certs. +1 for PEP with above changes. Ditto from me. In relation to changing the Python CLI API to offer some of the wget/curl style command line options, I like the idea of providing recipes in the docs for implementing them at the application layer, but postponing making the *default* behaviour configurable that way. I'm against any additional environment variables and command-line options. It will only complicate and obscure the security parameters of certificate validation. The existing knobs have already been mentioned in this thread, I won't mention them here again. Regards Antoine. ___ 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 476: Enabling certificate validation by default!
On Sun, 31 Aug 2014 03:25:25 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 31 Aug 2014 09:26:30 +1000 Nick Coghlan ncogh...@gmail.com 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 whether or not to raise an exception or warning. * choice of trusted certificate: Instead of hard wiring using the system CA roots into Python it would be good to just make this default and permit the user to point Python to a different set of CA roots. This would enable using self signed certs more easily. Since these are often used for tests, demos and education, I think it's important to allow having more control of the trusted certs. +1 for PEP with above changes. Ditto from me. In relation to changing the Python CLI API to offer some of the wget/curl style command line options, I like the idea of providing recipes in the docs for implementing them at the application layer, but postponing making the *default* behaviour configurable that way. I'm against any additional environment variables and command-line options. It will only complicate and obscure the security parameters of certificate validation. The existing knobs have already been mentioned in this thread, I won't mention them here again. Do those knobs allow one to instruct urllib to accept an invalid certificate without changing the program code? --David ___ 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 476: Enabling certificate validation by default!
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-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
