On 12.05.2015 05:03, Nick Coghlan wrote:
On 12 May 2015 at 04:49, M.-A. Lemburg m...@egenix.com 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
- Original Message -
From: Donald Stufft don...@stufft.io
To: Nick Coghlan ncogh...@gmail.com
Cc: python-dev python-dev@python.org, M.-A. Lemburg m...@egenix.com
Sent: Monday, May 11, 2015 1:16:58 PM
Subject: Re: [Python-Dev] PYTHONHTTPSVERIFY env var
On May 11, 2015, at 6:47
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
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 m...@egenix.com wrote:
On
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io 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
On 12.05.2015 13:21, Donald Stufft wrote:
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote:
If you control the app you don't need to do that. All relevant api accept
the context parameter. The shims are only
On 12 May 2015 at 17:57, M.-A. Lemburg m...@egenix.com 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
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io 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
On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote:
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote:
If you control the app you don't need to do that. All relevant api accept
the context parameter.
On 12.05.2015 12:04, Donald Stufft wrote:
On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com 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
On 12 May 2015 at 21:17, Nick Coghlan ncogh...@gmail.com 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
On 12 May 2015 at 21:45, Donald Stufft don...@stufft.io wrote:
On May 12, 2015, at 7:40 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote:
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09,
On May 12, 2015, at 7:40 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote:
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote:
If you control the app
On 12 May 2015 at 20:56, M.-A. Lemburg m...@egenix.com wrote:
On 12.05.2015 12:04, Donald Stufft wrote:
On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com wrote:
In a user based installation (which most applications shipping
their own Python installation are), you can always do this
On 12.05.2015 13:19, Nick Coghlan wrote:
On 12 May 2015 at 21:17, Nick Coghlan ncogh...@gmail.com 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
On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com 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
On 11 May 2015 at 18:04, M.-A. Lemburg m...@egenix.com wrote:
On 10.05.2015 05:04, Robert Collins wrote:
On 10 May 2015 at 11:44, Chris Angelico ros...@gmail.com wrote:
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg m...@egenix.com wrote:
By providing a way to intentionally switch off the new
On May 11, 2015, at 6:15 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 11 May 2015 at 19:22, M.-A. Lemburg m...@egenix.com 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
On 11 May 2015 at 20:23, Donald Stufft don...@stufft.io wrote:
On May 11, 2015, at 6:15 AM, Nick Coghlan ncogh...@gmail.com 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.
I'm in entire agreement with Donald below.
Regards
Antoine.
On Mon, 11 May 2015 06:23:11 -0400
Donald Stufft don...@stufft.io 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
On 11.05.2015 12:47, Nick Coghlan wrote:
On 11 May 2015 at 20:23, Donald Stufft don...@stufft.io wrote:
On May 11, 2015, at 6:15 AM, Nick Coghlan ncogh...@gmail.com wrote:
We made the decision when PEP 476 was accepted that this change turned
a silent security failure into a noisy one, rather
On 10.05.2015 05:04, Robert Collins wrote:
On 10 May 2015 at 11:44, Chris Angelico ros...@gmail.com wrote:
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg m...@egenix.com wrote:
By providing a way to intentionally switch off the new default,
we do make people aware of the risks and that's good
On 11.05.2015 11:13, Nick Coghlan wrote:
On 11 May 2015 at 18:04, M.-A. Lemburg m...@egenix.com wrote:
On 10.05.2015 05:04, Robert Collins wrote:
On 10 May 2015 at 11:44, Chris Angelico ros...@gmail.com wrote:
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg m...@egenix.com wrote:
By providing
On 11 May 2015 at 19:22, M.-A. Lemburg m...@egenix.com 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
On May 11, 2015, at 6:47 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 11 May 2015 at 20:23, Donald Stufft don...@stufft.io wrote:
On May 11, 2015, at 6:15 AM, Nick Coghlan ncogh...@gmail.com wrote:
We made the decision when PEP 476 was accepted that this change turned
a silent security
On 11 May 2015 10:16 pm, Robert Kuska rku...@redhat.com 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
On 11.05.2015 12:15, Nick Coghlan wrote:
On 11 May 2015 at 19:22, M.-A. Lemburg m...@egenix.com 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
On 12 May 2015 at 04:49, M.-A. Lemburg m...@egenix.com 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
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg m...@egenix.com 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
On 10 May 2015 at 13:04, Robert Collins robe...@robertcollins.net wrote:
On 10 May 2015 at 11:44, Chris Angelico ros...@gmail.com wrote:
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg m...@egenix.com wrote:
By providing a way to intentionally switch off the new default,
we do make people aware
On 10 May 2015 at 11:44, Chris Angelico ros...@gmail.com wrote:
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg m...@egenix.com 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
On 09.05.2015 02:29, Nick Coghlan wrote:
On 8 May 2015 8:14 pm, M.-A. Lemburg m...@egenix.com wrote:
On 08.05.2015 11:36, Nick Coghlan wrote:
On 8 May 2015 6:52 pm, M.-A. Lemburg m...@egenix.com wrote:
On 07.05.2015 04:30, Nick Coghlan wrote:
Can we please make the monkeypatch a regular
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 be good to
On 08.05.2015 11:36, Nick Coghlan wrote:
On 8 May 2015 6:52 pm, M.-A. Lemburg m...@egenix.com 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 m...@egenix.com 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
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
On 8 May 2015 9:52 pm, Antoine Pitrou solip...@pitrou.net 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,
On 8 May 2015 8:14 pm, M.-A. Lemburg m...@egenix.com wrote:
On 08.05.2015 11:36, Nick Coghlan wrote:
On 8 May 2015 6:52 pm, M.-A. Lemburg m...@egenix.com 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
38 matches
Mail list logo
