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? H
> -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
> Righ
> 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 propos
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
cr
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 23 Jan 2014 07:48, "Donald Stufft" 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" status.
Howeve
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 Wed, Jan 22, 2014 at 3:48 PM, Donald Stufft 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 anyway.
Never mind. If someone else cares they can propose it. I withdraw.
> On Jan 22, 2014, at 4:29 PM, Brett Cannon wrote:
>
>
>
>
>> On Wed, Jan 22, 2014 at 3:56 PM, Benjamin Peterson
>> wrote:
>>
>>
>> On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
>> > On 23 Jan 2014 00:39, "Benjam
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
On Wed, Jan 22, 2014 at 3:56 PM, Benjamin Peterson wrote:
>
>
> On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
> > On 23 Jan 2014 00:39, "Benjamin Peterson" wrote:
> > > Speaking of requests, I think another way to address this issue would
> be
> > > import a requests-like APIs into the s
On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
> On 23 Jan 2014 00:39, "Benjamin Peterson" 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 that verify c
On 23 Jan 2014 00:39, "Benjamin Peterson" wrote:
>
> On Wed, Jan 22, 2014, at 04:15 AM, Donald Stufft wrote:
> >
> > On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote:
> >
> > > On 22 January 2014 21:36, Donald Stufft wrote:
> > >> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
> > >>> The cha
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 un
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 warning
On Wed, 22 Jan 2014 13:50:37 -0500
Donald Stufft 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 the question of w
On Jan 22, 2014, at 1:46 PM, Brian Curtin wrote:
> On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong
> 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
On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong
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 internal application
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 e
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 Wed, 22 Jan 2014 08:12:06 -0700
Eric Snow wrote:
> On Jan 22, 2014 6:17 AM, "M.-A. Lemburg" 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 w
On 22 January 2014 10: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.
I'm overwhelmingly, dramatically +1 on this. There's no good
Donald Stufft 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
architect
On Wed, Jan 22, 2014, at 04:02 AM, Donald Stufft wrote:
>
> On Jan 22, 2014, at 6:45 AM, Nick Coghlan wrote:
>
> > On 22 January 2014 21:21, Paul Moore wrote:
> >> On 22 January 2014 10:30, Donald Stufft wrote:
> >>> Python 3.4 has made great strides in making it easier for applications
> >>>
On Jan 22, 2014 6:17 AM, "M.-A. Lemburg" 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 Jan 22, 2014, at 10:05 AM, Antoine Pitrou wrote:
> On Wed, 22 Jan 2014 15:33:21 +0100
> Christian Heimes 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
On Wed, 22 Jan 2014 15:33:21 +0100
Christian Heimes 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.
So why are you t
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, Jan 22, 2014, at 04:15 AM, Donald Stufft wrote:
>
> On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote:
>
> > On 22 January 2014 21:36, Donald Stufft wrote:
> >> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
> >>> The change would also disable all services using self-signed
> >>> cert
On Jan 22, 2014, at 9:33 AM, Christian Heimes 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, it's not been tri
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:28 AM, Paul Moore wrote:
> On 22 January 2014 13:29, Christian Heimes 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 again
On 22 January 2014 13:29, Christian Heimes 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
> you may overwrite
On Jan 22, 2014, at 9:19 AM, Paul Moore wrote:
> On 22 January 2014 13: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/statu
On 22 January 2014 13: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
Surprise that Python doesn't verify
On Wed, 22 Jan 2014 15:13:00 +0100
Christian Heimes 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 should not have t
On Thu, Jan 23, 2014 at 1:08 AM, Jesse Noller 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 needs it?
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 bre
> On Jan 22, 2014, at 8:03 AM, Christian Heimes 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
>> https://twitter.com/ojiidotch
On 22.01.2014 14:24, Nick Coghlan wrote:
> On 22 January 2014 23:19, Antoine Pitrou wrote:
>> On Wed, 22 Jan 2014 05:30:40 -0500
>> Donald Stufft wrote:
>>> I would like to propose that a backwards incompatible change be
>>> made to Python to make verification of hostname and certificate
>>> chai
> On Jan 22, 2014, at 6:58 AM, Chris Angelico wrote:
>
>> On Wed, Jan 22, 2014 at 11:15 PM, Donald Stufft 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
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 h
On Jan 22, 2014, at 8:29 AM, Christian Heimes 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 certificates th
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 t
On 22 January 2014 23:19, Antoine Pitrou wrote:
> On Wed, 22 Jan 2014 05:30:40 -0500
> 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 Wed, 22 Jan 2014 05:30:40 -0500
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
On 22 January 2014 22:15, Donald Stufft wrote:
>
> On Jan 22, 2014, at 6:58 AM, Nick Coghlan 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 even with the initial hash
On 22.01.2014 13:43, Jesse Noller wrote:
>> Well, it's not really a security issue, since the security features
>> are present in Python 3.4. It's just that the user has to enable them.
>
> I have to concur with Donald here - in the case of security, especially
> language security which directly
On Wed, Jan 22, 2014 at 11:15 PM, Donald Stufft 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 it's easy to twe
> On Jan 22, 2014, at 5:30 AM, "M.-A. Lemburg" wrote:
>
>> On 22.01.2014 11:56, Donald Stufft wrote:
>>
>>> On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg wrote:
>>>
On 22.01.2014 11:30, Donald Stufft wrote:
I would like to propose that a backwards incompatible change be made to
On 22 January 2014 12:02, Donald Stufft 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
On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote:
> On 22 January 2014 21:36, Donald Stufft wrote:
>> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
>>> The change would also disable all services using self-signed
>>> certificates which are very common in internal networks and
>>> for ad-hoc
On 22 January 2014 11:29, Donald Stufft 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 self-
On Jan 22, 2014, at 7:03 AM, Paul Moore wrote:
> On 22 January 2014 11:29, Donald Stufft 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* "lik
On Jan 22, 2014, at 6:45 AM, Nick Coghlan wrote:
> On 22 January 2014 21:21, Paul Moore wrote:
>> On 22 January 2014 10:30, Donald Stufft 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
>>
On 22 January 2014 21:36, Donald Stufft wrote:
> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg 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 self-signed
>>
On 22.01.2014 12:36, Donald Stufft wrote:
>
> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg 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 self-signed
>> ce
On 22 January 2014 21:21, Paul Moore wrote:
> On 22 January 2014 10:30, Donald Stufft 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 opt into this. Most assume that
On Jan 22, 2014, at 6:21 AM, Paul Moore 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 haven't opted in
On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
> On 22.01.2014 11:56, Donald Stufft wrote:
>>
>> On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg 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 m
On 22.01.2014 11:56, Donald Stufft wrote:
>
> On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg 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 de
On Jan 22, 2014, at 6:21 AM, Paul Moore wrote:
> On 22 January 2014 10:30, Donald Stufft 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 opt into this. Most assume
On 22 January 2014 10:30, Donald Stufft 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 opt into this. Most assume that it will operate
> similarly to their browser, cur
On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg 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
>> in.
>
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 fo
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 m
66 matches
Mail list logo
