A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2014-January/131933.html below:

[Python-Dev] Enable Hostname and Certificate Chain Validation

[Python-Dev] Enable Hostname and Certificate Chain ValidationNick Coghlan ncoghlan at gmail.com
Wed Jan 22 12:58:10 CET 2014
On 22 January 2014 21:36, Donald Stufft <donald at stufft.io> wrote:
> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg <mal at 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 self-signed
>> certificates when offering HTTPS services.
>
> It will just disable them by default, they can still easily be accessed
> you’d just need to pass the “do not verify” flag. This clearly indicates
> that you’re opting out of the S in HTTPS.

You need to remember that *Python is fundamentally not an
application*. We don't control the interaction with the user,
application developers do, and every decision we make has to take that
into account.

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 randomisation change
to avoid breaking currently working applications.

Look at the anger that people express about us making Python 3 more
sensitive to environment misconfiguration on POSIX systems: people
don't blame the misconfigured environment that Python 2 tolerated with
an increased risk of data corruption, they blame *us* for breaking
something that used to work by default.

The change you're proposing would mean that *every* Python application
would either need to be updated to explicitly opt in to insecurity
(the path most of them will take, because humans) or else to provide a
"set this option to make your computer work again" insecurity flag
(which is a bad idea anyway, again because humans).

There are currently still too many valid reasons for not using
verified SSL for us to realistically make it the default without a
seriously long transition period (not quite IPv6 or even Python 3
long, but certainly not as short as the time period involved in
introducing hash randomisation).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4