I would like to propose that a backwards incompatible change be
made to Python to make verification of hostname and certificate
chain the default instead of requiring it to be opt in.
Python 3.4 has made great strides in making it easier for applications
to simply turn on these settings, however
On 22.01.2014 11:30, Donald Stufft wrote:
I would like to propose that a backwards incompatible change be made to
Python to make
verification of hostname and certificate chain the default instead of
requiring it to be opt
in.
Python 3.4 has made great strides in making it easier for
On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg m...@egenix.com wrote:
On 22.01.2014 11:30, Donald Stufft wrote:
I would like to propose that a backwards incompatible change be made to
Python to make
verification of hostname and certificate chain the default instead of
requiring it to be opt
On Jan 22, 2014, at 6:21 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 22 January 2014 10:30, Donald Stufft don...@stufft.io wrote:
Python 3.4 has made great strides in making it easier for applications
to simply turn on these settings, however many people are not aware
at all that they need
On 22.01.2014 11:56, Donald Stufft wrote:
On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg m...@egenix.com wrote:
On 22.01.2014 11:30, Donald Stufft wrote:
I would like to propose that a backwards incompatible change be made to
Python to make
verification of hostname and certificate chain the
On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg m...@egenix.com wrote:
On 22.01.2014 11:56, Donald Stufft wrote:
On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg m...@egenix.com wrote:
On 22.01.2014 11:30, Donald Stufft wrote:
I would like to propose that a backwards incompatible change be made to
On Jan 22, 2014, at 6:21 AM, Paul Moore p.f.mo...@gmail.com wrote:
2. Your proposal is that because some application authors have not
opted in yet, we should penalise the end users of those applications
by stopping them being able to use unverified https? And don't forget,
applications that
On 22 January 2014 21:21, Paul Moore p.f.mo...@gmail.com wrote:
On 22 January 2014 10:30, Donald Stufft don...@stufft.io wrote:
Python 3.4 has made great strides in making it easier for applications
to simply turn on these settings, however many people are not aware
at all that they need to
On 22.01.2014 12:36, Donald Stufft wrote:
On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg m...@egenix.com wrote:
The change would also disable all services using self-signed
certificates which are very common in internal networks and
for ad-hoc setups. Many routers and other devices use
On 22 January 2014 21:36, Donald Stufft don...@stufft.io wrote:
On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg m...@egenix.com wrote:
The change would also disable all services using self-signed
certificates which are very common in internal networks and
for ad-hoc setups. Many routers and other
On Jan 22, 2014, at 6:45 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 January 2014 21:21, Paul Moore p.f.mo...@gmail.com wrote:
On 22 January 2014 10:30, Donald Stufft don...@stufft.io wrote:
Python 3.4 has made great strides in making it easier for applications
to simply turn on these
On Jan 22, 2014, at 7:03 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 22 January 2014 11:29, Donald Stufft don...@stufft.io wrote:
1. To be like the browser we'd need to use the OS certificate store,
which isn't the case on Windows at the moment (managing those
certificate bundle files is
On 22 January 2014 11:29, Donald Stufft don...@stufft.io wrote:
1. To be like the browser we'd need to use the OS certificate store,
which isn't the case on Windows at the moment (managing those
certificate bundle files is most definitely *not* like the browser -
I'd have no idea how to add a
On Jan 22, 2014, at 6:58 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 January 2014 21:36, Donald Stufft don...@stufft.io wrote:
On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg m...@egenix.com wrote:
The change would also disable all services using self-signed
certificates which are very
On 22 January 2014 12:02, Donald Stufft don...@stufft.io wrote:
We also have to account for the fact that an awful lot of Python
applications are corporate ones relying on perimeter defence for
security, or private CAs, or just self-signed certificates that their
users have already accepted.
On Jan 22, 2014, at 5:30 AM, M.-A. Lemburg m...@egenix.com wrote:
On 22.01.2014 11:56, Donald Stufft wrote:
On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg m...@egenix.com wrote:
On 22.01.2014 11:30, Donald Stufft wrote:
I would like to propose that a backwards incompatible change be made
On Wed, Jan 22, 2014 at 11:15 PM, Donald Stufft don...@stufft.io wrote:
Do you really think those people would be making the same complaints
if they could restore the previous behavior with a simple boolean flag
delivered either via environment variable or in their own code?
You assume that
On 22 January 2014 22:15, Donald Stufft don...@stufft.io wrote:
On Jan 22, 2014, at 6:58 AM, Nick Coghlan ncogh...@gmail.com wrote:
The kinds of decisions that an application like a web browser or a
package installer can make aren't necessarily available to a runtime.
We had to be cautious
On Wed, 22 Jan 2014 05:30:40 -0500
Donald Stufft don...@stufft.io wrote:
I would like to propose that a backwards incompatible change be
made to Python to make verification of hostname and certificate
chain the default instead of requiring it to be opt in.
Python 3.4 has made great strides
On 22 January 2014 23:19, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 22 Jan 2014 05:30:40 -0500
Donald Stufft don...@stufft.io wrote:
I would like to propose that a backwards incompatible change be
made to Python to make verification of hostname and certificate
chain the default
On 22.01.2014 12:45, Nick Coghlan wrote:
We also have to account for the fact that an awful lot of Python
applications are corporate ones relying on perimeter defence for
security, or private CAs, or just self-signed certificates that their
users have already accepted. There are limits to the
On Jan 22, 2014, at 8:29 AM, Christian Heimes christ...@python.org wrote:
On 22.01.2014 12:45, Nick Coghlan wrote:
We also have to account for the fact that an awful lot of Python
applications are corporate ones relying on perimeter defence for
security, or private CAs, or just self-signed
On 22.01.2014 14:55, Donald Stufft wrote:
As an additional side note, anecdotal evidence and what not, but
*every* time I bring this up somewhere I get at least one reply
that looks similar to
https://twitter.com/ojiidotch/status/425986619879866368
Yeah :(
The ssl module documentation
On Jan 22, 2014, at 6:58 AM, Chris Angelico ros...@gmail.com wrote:
On Wed, Jan 22, 2014 at 11:15 PM, Donald Stufft don...@stufft.io wrote:
Do you really think those people would be making the same complaints
if they could restore the previous behavior with a simple boolean flag
delivered
On 22.01.2014 14:24, Nick Coghlan wrote:
On 22 January 2014 23:19, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 22 Jan 2014 05:30:40 -0500
Donald Stufft don...@stufft.io wrote:
I would like to propose that a backwards incompatible change be
made to Python to make verification of hostname
On Jan 22, 2014, at 8:03 AM, Christian Heimes christ...@python.org wrote:
On 22.01.2014 14:55, Donald Stufft wrote:
As an additional side note, anecdotal evidence and what not, but
*every* time I bring this up somewhere I get at least one reply
that looks similar to
On 22.01.2014 13:43, Jesse Noller wrote:
I have to concur with Donald here - in the case of security, especially
language security which directly impacts the implicit security of downstream
applications, I should not have to opt in to the most secure defaults.
Yes; this potentially breaks
On Thu, Jan 23, 2014 at 1:08 AM, Jesse Noller jnol...@gmail.com wrote:
Now, maybe it wouldn't be a problem if the fix is an environment
variable, but imagine a thousand-computer deployment and you have to
tweak the environment on all of them. Feel like doing that just
because the newest Python
On Wed, 22 Jan 2014 15:13:00 +0100
Christian Heimes christ...@python.org wrote:
On 22.01.2014 13:43, Jesse Noller wrote:
I have to concur with Donald here - in the case of security, especially
language security which directly impacts the implicit security of
downstream applications, I
On 22 January 2014 13:55, Donald Stufft don...@stufft.io wrote:
As an additional side note, anecdotal evidence and what not, but
*every* time I bring this up somewhere I get at least one reply that
looks similar to https://twitter.com/ojiidotch/status/425986619879866368
Surprise that Python
On Jan 22, 2014, at 9:19 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 22 January 2014 13:55, Donald Stufft don...@stufft.io wrote:
As an additional side note, anecdotal evidence and what not, but
*every* time I bring this up somewhere I get at least one reply that
looks similar to
On 22 January 2014 13:29, Christian Heimes christ...@python.org wrote:
Side note:
Users can simple add self-signed certs to OpenSSL's cert store and get
validation for free. It's possible to do that with an environment
variable, too. But I recommend against the environment variable because
On Jan 22, 2014, at 9:28 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 22 January 2014 13:29, Christian Heimes christ...@python.org wrote:
Side note:
Users can simple add self-signed certs to OpenSSL's cert store and get
validation for free. It's possible to do that with an environment
On 22.01.2014 15:12, Jesse Noller wrote:
And no one reads it. I can't count the number of times I've gotten called
into a managers office when they find out python doesn't do cert validation
by default (and in 2, it's not been trivial) and gotten told to fix it, or we
move off of python.
On Jan 22, 2014, at 9:33 AM, Christian Heimes christ...@python.org wrote:
On 22.01.2014 15:12, Jesse Noller wrote:
And no one reads it. I can't count the number of times I've gotten called
into a managers office when they find out python doesn't do cert validation
by default (and in 2,
On Wed, Jan 22, 2014, at 04:15 AM, Donald Stufft wrote:
On Jan 22, 2014, at 6:58 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 January 2014 21:36, Donald Stufft don...@stufft.io wrote:
On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg m...@egenix.com wrote:
The change would also disable all
On 22.01.2014 15:36, Donald Stufft wrote:
Last time I tried the reasoning was that Python couldn’t ship root certs
and we couldn’t get to the OS certs everywhere. Thanks to you this
is fixed now, so “once more unto the breach”.
The Windows situation is still not perfect, though. I'd love to
On Wed, 22 Jan 2014 15:33:21 +0100
Christian Heimes christ...@python.org wrote:
About two months ago (maybe three) I proposed to deprecated implicit SSL
context, unverified certs and unverified hostnames all together. But I
was voted down. Donald made a similar attempt half an year ago, too.
On Jan 22, 2014, at 10:05 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 22 Jan 2014 15:33:21 +0100
Christian Heimes christ...@python.org wrote:
About two months ago (maybe three) I proposed to deprecated implicit SSL
context, unverified certs and unverified hostnames all together.
On Jan 22, 2014 6:17 AM, M.-A. Lemburg m...@egenix.com wrote:
Using an environment switch the extra checks could even be enabled
without any code changes.
When Donald brought this up it sounded good. It still does. This is
similar to what we did for hash randomization.
-eric
On Wed, Jan 22, 2014, at 04:02 AM, Donald Stufft wrote:
On Jan 22, 2014, at 6:45 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 January 2014 21:21, Paul Moore p.f.mo...@gmail.com wrote:
On 22 January 2014 10:30, Donald Stufft don...@stufft.io wrote:
Python 3.4 has made great strides
Donald Stufft donald at stufft.io writes:
I would like to propose that a backwards incompatible change be
made to Python to make verification of hostname and certificate
chain the default instead of requiring it to be opt in.
I'm overwhelmingly, dramatically +1 on this. There's no good
On 22 January 2014 10:30, Donald Stufft don...@stufft.io wrote:
I would like to propose that a backwards incompatible change be
made to Python to make verification of hostname and certificate
chain the default instead of requiring it to be opt in.
I'm overwhelmingly, dramatically +1 on this.
On Wed, 22 Jan 2014 08:12:06 -0700
Eric Snow ericsnowcurren...@gmail.com wrote:
On Jan 22, 2014 6:17 AM, M.-A. Lemburg m...@egenix.com wrote:
Using an environment switch the extra checks could even be enabled
without any code changes.
When Donald brought this up it sounded good. It still
20.01.14 13:14, Serhiy Storchaka написав(ла):
Contestant 5: Put in __clinic__ directory, add .h
foo.c - __clinic__/foo.c.h
foo.h - __clinic__/foo.h.h
-0.5.
As far as 4 and 5 have equal total votes, I change my vote for 5 from
-0.5 to -0.
On 1/22/14 8:16 AM, Nick Coghlan wrote:
Which is exactly the way most non-web-specialists working inside the
comfort of corporate and academic firewalls will react to a change
that breaks their access to internal applications, where self-signed
certs and improperly configured internal CAs are
On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong
gokoproj...@gmail.com wrote:
On 1/22/14 8:16 AM, Nick Coghlan wrote:
Which is exactly the way most non-web-specialists working inside the
comfort of corporate and academic firewalls will react to a change that
breaks their access to
On Jan 22, 2014, at 1:46 PM, Brian Curtin br...@python.org wrote:
On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong
gokoproj...@gmail.com wrote:
On 1/22/14 8:16 AM, Nick Coghlan wrote:
Which is exactly the way most non-web-specialists working inside the
comfort of corporate and
On Wed, 22 Jan 2014 13:50:37 -0500
Donald Stufft don...@stufft.io wrote:
Ironically this is the exact reason why validation should happen by default :]
I think most of us would agree that a new client API should do
validation by default (with an easy way to opt out). So let's
concentrate on
If I could summarize this discussion (please correct me if I am wrong):
1. Status Quo
All existing versions of Python are unsecure by default
because by not doing SSL hostname verification,
libraries which wrap sockets with SSLContext
allow SSL MITM (man-in-the-middle) with no
On 1/22/2014 9:25 AM, Donald Stufft wrote:
Awesome, It looks like I’ll be writing a PEP to handle this, I wasn’t
sure if it needed one or not.
Definitely. I think the transition from insecure by default to secure by
default is somewhat comparable to the transition from ascii by default
to
On 23 Jan 2014 00:39, Benjamin Peterson benja...@python.org wrote:
On Wed, Jan 22, 2014, at 04:15 AM, Donald Stufft wrote:
On Jan 22, 2014, at 6:58 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 January 2014 21:36, Donald Stufft don...@stufft.io wrote:
On Jan 22, 2014, at 6:30 AM,
On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
On 23 Jan 2014 00:39, Benjamin Peterson benja...@python.org wrote:
Speaking of requests, I think another way to address this issue would be
import a requests-like APIs into the stdlib (something which should
happen anyway) and make
On Wed, Jan 22, 2014 at 3:56 PM, Benjamin Peterson benja...@python.orgwrote:
On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
On 23 Jan 2014 00:39, Benjamin Peterson benja...@python.org wrote:
Speaking of requests, I think another way to address this issue would
be
import a
On 01/22/2014 08:20 AM, Serhiy Storchaka wrote:
20.01.14 13:14, Serhiy Storch
aka написав(ла):
Contestant 5: Put in __clinic__ directory, add .h
foo.c - __clinic__/foo.c.h
foo.h - __clinic__/foo.h.h
-0.5.
As far as 4 and 5 have equal total votes, I change my vote for 5 from
Never mind. If someone else cares they can propose it. I withdraw.
On Jan 22, 2014, at 4:29 PM, Brett Cannon br...@python.org wrote:
On Wed, Jan 22, 2014 at 3:56 PM, Benjamin Peterson benja...@python.org
wrote:
On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
On 23 Jan
On Wed, Jan 22, 2014 at 3:48 PM, Donald Stufft don...@stufft.io wrote:
Never mind. If someone else cares they can propose it. I withdraw.
I'll throw writing a PEP for 3.5 to do this following the deprecation
policy on my todo list so 3.4 fixing can move on. I needed to brush up
on my ReST
On Wed, Jan 22, 2014, at 01:48 PM, Donald Stufft wrote:
Never mind. If someone else cares they can propose it. I withdraw.
I'm sorry to see this thread went down hill so quickly. I think we can
all agree than not validating certs by default is bad and that it should
change soon. It's only a
On 23 Jan 2014 07:48, Donald Stufft don...@stufft.io wrote:
Never mind. If someone else cares they can propose it. I withdraw.
That's unfortunate, but understandable - we already have a lot to deal with
just trying to get even the software distribution infrastructure to a
secure by default
On 1/22/2014 4:41 PM, Larry Hastings wrote:
And yes, with 13 votes cast, it ended with a tie between
clinic/{filename}.h and __clinic__/{filename}.h, both at +4. As
officiant I get to be the tiebreaker.
Yep.
My thoughts so far:
* A bunch of longtime Python core devs cast their votes for
On 22.01.2014 23:20, Nick Coghlan wrote:
However, now we have access to the system cert stores on all major
platforms, I *do* think it's a good idea to eventually change the
default settings to include host verification.
Somebody has revise the situation on OSX for Python 3.5 and possible
While the normal deprecation process should suffice, that still means Python
3.6 (2017-ish) is the earliest feasible target for new default settings.
Could a CERT_NOVERIFY no-op be added now?
(no-op because it would just be more explicit about the default
behavior anyway) [1]
Such a proposal
-Original Message-
From: Python-Dev [mailto:python-dev-
bounces+kristjan=ccpgames@python.org] On Behalf Of Nick Coghlan
Sent: Wednesday, January 22, 2014 19:45
To: Paul Moore
Cc: Python-Dev
Subject: Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
Right, the
On 2014-01-22 9:33 AM, Donald Stufft wrote:
For everything but pip, you’d add it to your OS cert store. Pip doesn’t
use that so you’d have to use the —cert config.
What if I don't want that self-signed cert to be trusted by all users on
the system? What if I don't have administrative rights?
64 matches
Mail list logo
