On Tue, Jun 4, 2013 at 9:15 AM, Donald Stufft don...@stufft.io wrote:
Generally any of these will be completely valid options, even disabling the
checks. The idea behind my proposal is that people generally only use TLS
for a reason and that reason is they want to protect against the kinds of
On 3 Jun, 2013, at 7:58, Benjamin Peterson benja...@python.org wrote:
2013/6/2 Donald Stufft don...@stufft.io:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is no
guaranteed certificates available.
2013/6/2 Donald Stufft don...@stufft.io:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is no
guaranteed certificates available.
So I would like to propose that CPython adopt the Mozilla SSL certificate
On Jun 3, 2013, at 1:58 AM, Benjamin Peterson benja...@python.org wrote:
2013/6/2 Donald Stufft don...@stufft.io:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is no
guaranteed certificates available.
2013/6/3 Donald Stufft don...@stufft.io:
On Jun 3, 2013, at 1:58 AM, Benjamin Peterson benja...@python.org wrote:
2013/6/2 Donald Stufft don...@stufft.io:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because
Love this idea. Some third-party HTTP libraries turn this on by
default in any case (eg: requests, and I think others), so this would
mean Python would get their safe-by-default behaviour in its stdlib.
Ideally this would take the shape of attempting to locate the system
certificate store if
On Mon, 3 Jun 2013 01:20:42 -0400
Donald Stufft don...@stufft.io wrote:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is
no guaranteed certificates available.
Also for backwards compatibility.
Regards
On Sun, 2 Jun 2013 22:57:15 -0700
Chris Rebert c...@rebertia.com wrote:
On Jun 2, 2013 10:22 PM, Donald Stufft don...@stufft.io wrote:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is no
On Mon, 03 Jun 2013 19:38:45 +1200, Ben Hoyt benh...@gmail.com wrote:
Love this idea. Some third-party HTTP libraries turn this on by
default in any case (eg: requests, and I think others), so this would
mean Python would get their safe-by-default behaviour in its stdlib.
Ideally this
The situation for certs is probably fairly parallel: on unix, it would
probably be an advantage as Python would automatically follow distro
decisions about cert chains, while on windows trying to use a system
cert store would probably be a disaster.
Yeah, fair enough. If it's stable and just
Am 03.06.2013 07:20, schrieb Donald Stufft:
Ideally this would take the shape of attempting to locate the system
certificate store if possible, and if that doesn't work falling back to
the bundled certificates. That way the various Linux distros can easily
have their copies of Python depend
On Mon, 3 Jun 2013 21:37:10 +1200
Ben Hoyt benh...@gmail.com wrote:
I'm not familiar with Unix/Linux, but on Windows, if it's anything
like mimetypes it'll be really hard to get consistent behaviour across
different boxes/versions from the registry, or wherever certs might be
stored on
I'm not familiar with Unix/Linux, but on Windows, if it's anything
like mimetypes it'll be really hard to get consistent behaviour across
different boxes/versions from the registry, or wherever certs might be
stored on Windows. I'd much rather have a slightly outdated but
consistent
On Mon, Jun 3, 2013 at 1:20 AM, Donald Stufft don...@stufft.io wrote:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is no
guaranteed certificates available.
So I would like to propose that CPython
On 06/02/2013 10:20 PM, Donald Stufft wrote:
So I would like to propose that CPython adopt the Mozilla SSL certificate list
and include it in core, and switch over
the API's so that they verify HTTPS by default.
+1
Also, +1 on using system certs when available.
--
~Ethan~
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 3 Jun 2013 21:37:10 +1200
Ben Hoyt benh...@gmail.com wrote:
I'm not familiar with Unix/Linux, but on Windows, if it's anything
like mimetypes it'll be really hard to get consistent behaviour across
different
On Mon, 3 Jun 2013 12:43:32 -0400
Donald Stufft don...@stufft.io wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 3 Jun 2013 21:37:10 +1200
Ben Hoyt benh...@gmail.com wrote:
I'm not familiar with Unix/Linux, but on Windows, if it's anything
like
On 06/03/2013 09:43 AM, Donald Stufft wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
The problem with a slightly outdated CA store is that it can be a
security risk.
Tracking the Mozilla store isn't difficult. New additions can be ignored for
currently released Pythons so we'd
On Jun 3, 2013, at 12:52 PM, Ethan Furman et...@stoneleaf.us wrote:
On 06/03/2013 09:43 AM, Donald Stufft wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
The problem with a slightly outdated CA store is that it can be a
security risk.
Tracking the Mozilla store isn't difficult.
On Jun 03, 2013, at 01:20 AM, Donald Stufft wrote:
So I would like to propose that CPython adopt the Mozilla SSL certificate
list and include it in core, and switch over the API's so that they verify
HTTPS by default. This is what most people are going to expect when using a
https url (Especially
On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
The data is analogous to the time zone database (PEP 431) in that it may
need to be updated independently of Python's own release schedule, so we
may want to use similar techniques to manage both. Also see certifi (
On Jun 3, 2013, at 12:36 PM, Barry Warsaw ba...@python.org wrote:
On Jun 03, 2013, at 01:20 AM, Donald Stufft wrote:
So I would like to propose that CPython adopt the Mozilla SSL certificate
list and include it in core, and switch over the API's so that they verify
HTTPS by default. This
On Jun 03, 2013, at 03:12 AM, Donald Stufft wrote:
That's fine with me too. My only reason for wanting to use the system certs
first is so if someone has modified their system certs (say to include a
corporate cert) that it would ideally take affect for Python as well.
This reminds me of one
On Jun 3, 2013, at 12:52 PM, Barry Warsaw ba...@python.org wrote:
On Jun 03, 2013, at 03:12 AM, Donald Stufft wrote:
That's fine with me too. My only reason for wanting to use the system certs
first is so if someone has modified their system certs (say to include a
corporate cert) that it
On Jun 03, 2013, at 02:21 PM, Donald Stufft wrote:
The other additional comment I'd like to throw in here is that if we don't
bundle SSL certs I think we should still verify by default (which means HTTPS
urls will throw an error by default if we can't locate a certificate store)
because I think
On Jun 3, 2013, at 12:48 PM, Barry Warsaw ba...@python.org wrote:
On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
The data is analogous to the time zone database (PEP 431) in that it may
need to be updated independently of Python's own release schedule, so we
may want to use similar
On Jun 03, 2013, at 02:17 PM, Donald Stufft wrote:
I'd actually prefer for Linux to not use the bundled certs when installed
from a package manager because it should use the system certs, but people
can't depend on certs being there if they are only there on linux.
I think we agree on that.
On 06/03/2013 10:55 AM, Donald Stufft wrote:
On Jun 3, 2013, at 12:52 PM, Ethan Furman wrote:
On 06/03/2013 09:43 AM, Donald Stufft wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
The problem with a slightly outdated CA store is that it can be a
security risk.
Tracking the Mozilla
On Mon, 3 Jun 2013 14:12:34 -0400
Donald Stufft don...@stufft.io wrote:
I worry with the current situation people will just use TLS connections
without realizing it's not being verified and thinking they are safe.
Yet there's quite a visible warning in the docs:
On Jun 3, 2013, at 1:07 PM, Barry Warsaw ba...@python.org wrote:
On Jun 03, 2013, at 02:17 PM, Donald Stufft wrote:
I'd actually prefer for Linux to not use the bundled certs when installed
from a package manager because it should use the system certs, but people
can't depend on certs
On Mon, Jun 3, 2013 at 1:04 PM, Barry Warsaw ba...@python.org wrote:
On Jun 03, 2013, at 02:21 PM, Donald Stufft wrote:
The other additional comment I'd like to throw in here is that if we don't
bundle SSL certs I think we should still verify by default (which means
HTTPS
urls will throw an
On 06/03/2013 11:34 AM, Antoine Pitrou wrote:
On Mon, 3 Jun 2013 14:12:34 -0400
Donald Stufft wrote:
I worry with the current situation people will just use TLS connections without realizing
it's not being verified and thinking they are safe.
Yet there's quite a visible warning in the docs:
On Mon, 03 Jun 2013 11:56:45 -0700
Ethan Furman et...@stoneleaf.us wrote:
On 06/03/2013 11:34 AM, Antoine Pitrou wrote:
On Mon, 3 Jun 2013 14:12:34 -0400
Donald Stufft wrote:
I worry with the current situation people will just use TLS connections
without realizing it's not being
On Tue, Jun 4, 2013 at 4:56 AM, Ethan Furman et...@stoneleaf.us wrote:
On 06/03/2013 11:34 AM, Antoine Pitrou wrote:
On Mon, 3 Jun 2013 14:12:34 -0400
Donald Stufft wrote:
I worry with the current situation people will just use TLS connections
without realizing it's not being verified and
On Mon, 2013-06-03 at 12:48 -0400, Barry Warsaw wrote:
On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
The data is analogous to the time zone database (PEP 431) in that it may
need to be updated independently of Python's own release schedule, so we
may want to use similar techniques to
Am 03.06.2013 21:52, schrieb Antoine Pitrou:
cadefault=True will probably be fail if the system certs are not
properly configured in OpenSSL, e.g. under Windows or with a hand-made
OpenSSL build.
And, because of the way the OpenSSL API works, there's no way of
knowing if it is the case or
On Jun 3, 2013, at 4:19 PM, Christian Heimes christ...@python.org wrote:
Am 03.06.2013 21:52, schrieb Antoine Pitrou:
cadefault=True will probably be fail if the system certs are not
properly configured in OpenSSL, e.g. under Windows or with a hand-made
OpenSSL build.
And, because of the
In article 699d9ab5-26e0-4cce-89c5-8e92c3305...@stufft.io,
Donald Stufft don...@stufft.io wrote:
On Jun 3, 2013, at 4:19 PM, Christian Heimes christ...@python.org wrote:
Most Linux and BSD-ish operating systems have SSL certs at some standard
location.
On 3 June 2013 21:05, Chris Angelico ros...@gmail.com wrote:
+1 for having the default be safe, but this will have to be very
loudly announced (when migrating from 3.3 to 3.4, TLS connections
will cease to work if blah blah).
+1 on the default being safe, certainly. But with the proviso that
On Mon, 3 Jun 2013 22:31:40 +0100
Paul Moore p.f.mo...@gmail.com wrote:
Some legit sites with proper
certificates still manage to muck something up administratively
(developer.quicksales.com.au has a cert from RapidSSL but doesn't
bundle the intermediates, and I've told their devs about
On Tue, Jun 4, 2013 at 7:31 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 3 June 2013 21:05, Chris Angelico ros...@gmail.com wrote:
Some legit sites with proper
certificates still manage to muck something up administratively
(developer.quicksales.com.au has a cert from RapidSSL but doesn't
On Jun 3, 2013, at 5:41 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 3 Jun 2013 22:31:40 +0100
Paul Moore p.f.mo...@gmail.com wrote:
Some legit sites with proper
certificates still manage to muck something up administratively
(developer.quicksales.com.au has a cert from RapidSSL
On Jun 3, 2013, at 5:31 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 3 June 2013 21:05, Chris Angelico ros...@gmail.com wrote:
+1 for having the default be safe, but this will have to be very
loudly announced (when migrating from 3.3 to 3.4, TLS connections
will cease to work if blah
On Mon, 3 Jun 2013 17:47:31 -0400
Donald Stufft don...@stufft.io wrote:
On Jun 3, 2013, at 5:41 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 3 Jun 2013 22:31:40 +0100
Paul Moore p.f.mo...@gmail.com wrote:
Some legit sites with proper
certificates still manage to muck
On Jun 3, 2013, at 5:51 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 3 Jun 2013 17:47:31 -0400
Donald Stufft don...@stufft.io wrote:
On Jun 3, 2013, at 5:41 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 3 Jun 2013 22:31:40 +0100
Paul Moore p.f.mo...@gmail.com wrote:
On 3 June 2013 22:46, Donald Stufft don...@stufft.io wrote:
Also, we should consider the issue for application users. Suppose I'm
using a Python application that downloads something from the web. I upgrade
to 3.4, and the app stops working because of a will cease to work case.
As an end user,
On Jun 3, 2013, at 6:01 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 3 June 2013 22:46, Donald Stufft don...@stufft.io wrote:
Also, we should consider the issue for application users. Suppose I'm using
a Python application that downloads something from the web. I upgrade to
3.4, and the
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is no
guaranteed certificates available.
So I would like to propose that CPython adopt the Mozilla SSL certificate list
and include it in core, and switch
On Jun 2, 2013 10:22 PM, Donald Stufft don...@stufft.io wrote:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is no
guaranteed certificates available.
Relevant: http://bugs.python.org/issue13647
So
49 matches
Mail list logo
