On 05/12/2015 04:19 AM, Nick Coghlan wrote:
It occurs to me that the subtitle of PEP 493 could be "All software is
terrible, but it's often a system administrator's job to make it run
anyway" :)
+1 QoTW
--
~Ethan~
___
Python-Dev mailing list
Python
On 12 May 2015 at 21:45, Donald Stufft wrote:
>
>> On May 12, 2015, at 7:40 AM, Nick Coghlan wrote:
>>
>> On 12 May 2015 at 21:21, Donald Stufft wrote:
>>>
On May 12, 2015, at 7:17 AM, Nick Coghlan wrote:
On 12 May 2015 at 21:09, Donald Stufft wrote:
> If you control the app
> On May 12, 2015, at 7:40 AM, Nick Coghlan wrote:
>
> On 12 May 2015 at 21:21, Donald Stufft wrote:
>>
>>> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote:
>>>
>>> On 12 May 2015 at 21:09, Donald Stufft wrote:
If you control the app you don't need to do that. All relevant api accept
On 12.05.2015 13:21, Donald Stufft wrote:
>
>> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote:
>>
>> On 12 May 2015 at 21:09, Donald Stufft wrote:
>>> If you control the app you don't need to do that. All relevant api accept
>>> the context parameter. The shims are only useful when you don't c
On 12 May 2015 at 21:21, Donald Stufft wrote:
>
>> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote:
>>
>> On 12 May 2015 at 21:09, Donald Stufft wrote:
>>> If you control the app you don't need to do that. All relevant api accept
>>> the context parameter. The shims are only useful when you don
> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote:
>
> On 12 May 2015 at 21:09, Donald Stufft wrote:
>> If you control the app you don't need to do that. All relevant api accept
>> the context parameter. The shims are only useful when you don't control the
>> app. So an app shipping their own
On 12.05.2015 13:19, Nick Coghlan wrote:
> On 12 May 2015 at 21:17, Nick Coghlan wrote:
>> Both of those make sense to me as cases where the environment variable
>> based security downgrade approach is the "least bad" answer available,
>> which is why I eventually agreed it should be one of the
>>
On 12 May 2015 at 21:17, Nick Coghlan wrote:
> Both of those make sense to me as cases where the environment variable
> based security downgrade approach is the "least bad" answer available,
> which is why I eventually agreed it should be one of the
> recommendations in the PEP.
It occurs to me t
On 12 May 2015 at 21:09, Donald Stufft wrote:
> If you control the app you don't need to do that. All relevant api accept the
> context parameter. The shims are only useful when you don't control the app.
> So an app shipping their own python doesn't fall under that.
I think the "bundled Python
On 12 May 2015 at 20:56, M.-A. Lemburg wrote:
> On 12.05.2015 12:04, Donald Stufft wrote:
>>
>>> On May 12, 2015, at 3:57 AM, M.-A. Lemburg wrote:
>>>
>>> In a user based installation (which most applications shipping
>>> their own Python installation are), you can always do this
>>> provided you
If you control the app you don't need to do that. All relevant api accept the
context parameter. The shims are only useful when you don't control the app. So
an app shipping their own python doesn't fall under that.
> On May 12, 2015, at 6:56 AM, M.-A. Lemburg wrote:
>
>> On 12.05.2015 12:04,
On 12.05.2015 12:04, Donald Stufft wrote:
>
>> On May 12, 2015, at 3:57 AM, M.-A. Lemburg wrote:
>>
>> In a user based installation (which most applications shipping
>> their own Python installation are), you can always do this
>> provided you can gain the application user permissions.
>
> Of co
> On May 12, 2015, at 3:57 AM, M.-A. Lemburg wrote:
>
> In a user based installation (which most applications shipping
> their own Python installation are), you can always do this
> provided you can gain the application user permissions.
Of course, if the application is shipping it’s own Python
On 12 May 2015 at 17:57, M.-A. Lemburg wrote:
> The point here is that sys admins should not
> have to patch Python to make things work again, in case
> an application is not prepared for the certificate
> verification - which is rather likely, since the pre-Python
> 2.7.9 doesn't even provide the
- Original Message -
> From: "Donald Stufft"
> To: "Nick Coghlan"
> Cc: "python-dev" , "M.-A. Lemburg"
> Sent: Monday, May 11, 2015 1:16:58 PM
> Subject: Re: [Python-Dev] PYTHONHTTPSVERIFY env var
>
>
> > On May 11
On 12.05.2015 05:03, Nick Coghlan wrote:
> On 12 May 2015 at 04:49, M.-A. Lemburg wrote:
>> On 11.05.2015 12:15, Nick Coghlan wrote:
>>> By contrast, the configuration file shouldn't provide a new attack
>>> vector (or simplify any existing attack vector), as if you have the
>>> permissions needed
On 12 May 2015 at 04:49, M.-A. Lemburg wrote:
> On 11.05.2015 12:15, Nick Coghlan wrote:
>> By contrast, the configuration file shouldn't provide a new attack
>> vector (or simplify any existing attack vector), as if you have the
>> permissions needed to modify the config file, you likely also hav
On 11.05.2015 12:15, Nick Coghlan wrote:
> On 11 May 2015 at 19:22, M.-A. Lemburg wrote:
>> On 11.05.2015 11:13, Nick Coghlan wrote:
>>> I wouldn't be opposed to seeing that as an upstream Python 2.7.x
>>> feature, but agreement amongst redistributors on using a file-based
>>> approach is the main
On 11 May 2015 10:16 pm, "Robert Kuska" wrote:
> > >
> >
> > Oh, another issue that I forgot to mention--
> >
> > A fair number of people had no idea that Python wasn't validating TLS
before
> > 2.7.9/3.4.3 however as part of the processing of changing that in 2.7.9
a lot
> > of people became awa
> On May 11, 2015, at 6:47 AM, Nick Coghlan wrote:
>
> On 11 May 2015 at 20:23, Donald Stufft wrote:
>> On May 11, 2015, at 6:15 AM, Nick Coghlan wrote:
>>> We made the decision when PEP 476 was accepted that this change turned
>>> a silent security failure into a noisy one, rather than being
On 11.05.2015 12:47, Nick Coghlan wrote:
> On 11 May 2015 at 20:23, Donald Stufft wrote:
>> On May 11, 2015, at 6:15 AM, Nick Coghlan wrote:
>>> We made the decision when PEP 476 was accepted that this change turned
>>> a silent security failure into a noisy one, rather than being a
>>> regressio
On 11 May 2015 at 20:23, Donald Stufft wrote:
> On May 11, 2015, at 6:15 AM, Nick Coghlan wrote:
>> We made the decision when PEP 476 was accepted that this change turned
>> a silent security failure into a noisy one, rather than being a
>> regression in its own right. PEP 493 isn't about disagre
I'm in entire agreement with Donald below.
Regards
Antoine.
On Mon, 11 May 2015 06:23:11 -0400
Donald Stufft wrote:
>
> I don't really agree that the decision to disable TLS is an environment one,
> it's really a per application decision. This is why I was against having some
> sort of glob
> On May 11, 2015, at 6:15 AM, Nick Coghlan wrote:
>
> On 11 May 2015 at 19:22, M.-A. Lemburg wrote:
>> On 11.05.2015 11:13, Nick Coghlan wrote:
>>> I wouldn't be opposed to seeing that as an upstream Python 2.7.x
>>> feature, but agreement amongst redistributors on using a file-based
>>> appro
On 11 May 2015 at 19:22, M.-A. Lemburg wrote:
> On 11.05.2015 11:13, Nick Coghlan wrote:
>> I wouldn't be opposed to seeing that as an upstream Python 2.7.x
>> feature, but agreement amongst redistributors on using a file-based
>> approach is the main outcome I'm looking for.
>
> Can't we have bot
On 11.05.2015 11:13, Nick Coghlan wrote:
> On 11 May 2015 at 18:04, M.-A. Lemburg wrote:
>> On 10.05.2015 05:04, Robert Collins wrote:
>>> On 10 May 2015 at 11:44, Chris Angelico wrote:
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg wrote:
> By providing a way to intentionally switch of
On 11 May 2015 at 18:04, M.-A. Lemburg wrote:
> On 10.05.2015 05:04, Robert Collins wrote:
>> On 10 May 2015 at 11:44, Chris Angelico wrote:
>>> On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg wrote:
By providing a way to intentionally switch off the new default,
we do make people aware
On 10.05.2015 05:04, Robert Collins wrote:
> On 10 May 2015 at 11:44, Chris Angelico wrote:
>> On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg wrote:
>>> By providing a way to intentionally switch off the new default,
>>> we do make people aware of the risks and that's good enough,
>>> while still
On 10 May 2015 at 13:04, Robert Collins wrote:
> On 10 May 2015 at 11:44, Chris Angelico wrote:
>> On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg wrote:
>>> By providing a way to intentionally switch off the new default,
>>> we do make people aware of the risks and that's good enough,
>>> while
On 10 May 2015 at 11:44, Chris Angelico wrote:
> On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg wrote:
>> By providing a way to intentionally switch off the new default,
>> we do make people aware of the risks and that's good enough,
>> while still maintaining the contract people rightly expect o
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg wrote:
> By providing a way to intentionally switch off the new default,
> we do make people aware of the risks and that's good enough,
> while still maintaining the contract people rightly expect of
> patch level releases of Python.
Just as long as
On 09.05.2015 02:29, Nick Coghlan wrote:
> On 8 May 2015 8:14 pm, "M.-A. Lemburg" wrote:
>>
>> On 08.05.2015 11:36, Nick Coghlan wrote:
>>> On 8 May 2015 6:52 pm, "M.-A. Lemburg" wrote:
On 07.05.2015 04:30, Nick Coghlan wrote:
>> Can we please make the monkeypatch a regular part of
On 8 May 2015 8:14 pm, "M.-A. Lemburg" wrote:
>
> On 08.05.2015 11:36, Nick Coghlan wrote:
> > On 8 May 2015 6:52 pm, "M.-A. Lemburg" wrote:
> >>
> >> On 07.05.2015 04:30, Nick Coghlan wrote:
> Can we please make the monkeypatch a regular part of Python's
> site.py which can enabled via
On 8 May 2015 9:52 pm, "Antoine Pitrou" wrote:
>
>
> Using an environment variable to disable a security feature sounds like
> an extremely bad idea. Environment variables are hidden state.
> Generally you don't know up front which values they will have when
> running an executable, and people don
Using an environment variable to disable a security feature sounds like
an extremely bad idea. Environment variables are hidden state.
Generally you don't know up front which values they will have when
running an executable, and people don't think about inspecting them.
This opens the door to mist
On 08.05.2015 11:36, Nick Coghlan wrote:
> On 8 May 2015 6:52 pm, "M.-A. Lemburg" wrote:
>>
>> On 07.05.2015 04:30, Nick Coghlan wrote:
Can we please make the monkeypatch a regular part of Python's
site.py which can enabled via an environment variable, say
export PYTHONHTTPSVERIFY=0
On 8 May 2015 6:52 pm, "M.-A. Lemburg" wrote:
>
> On 07.05.2015 04:30, Nick Coghlan wrote:
> >> Can we please make the monkeypatch a regular part of Python's
> >> site.py which can enabled via an environment variable, say
> >> export PYTHONHTTPSVERIFY=0.
> >>
> >> See http://bugs.python.org/issue2
On 07.05.2015 04:30, Nick Coghlan wrote:
>> Can we please make the monkeypatch a regular part of Python's
>> site.py which can enabled via an environment variable, say
>> export PYTHONHTTPSVERIFY=0.
>>
>> See http://bugs.python.org/issue23857 for the discussion.
> ...
> I actually do think it would
38 matches
Mail list logo
