[Python-Dev] Enable Hostname and Certificate Chain Validation (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Jan 22 14:16:44 CET 2014

On 22 January 2014 22:15, Donald Stufft <donald at stufft.io> wrote:

On Jan 22, 2014, at 6:58 AM, Nick Coghlan <ncoghlan at 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 even with the initial hash randomisation change to avoid breaking currently working applications. The same could be said for requests, it’s fundamentally not an application and can’t control the interaction with the user and yet it validates TLS by default just fine.

The requests library is used by a relatively small fraction of the Python community, and they're mostly web specialists that already understand the need for TLS-by-default and hence don't need it carefully explained to them. New users adopting it just treat that as the "way that requests works" and not something the language developers are forcing on them.

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. They blame Python for breaking something that used to work by default for something they feel has little or no benefit, and which is also difficult or impossible to adapt to without often significant code changes (for the people who I’ve seen blaming Python dev for).

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 endemic (of course, that's assuming they're using HTTPS at all, which I admit is an optimistic assumption).

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). As I’ve said multiple times, I think it’s fine to send it through the deprecation process which is still pretty long and gives people a good chunk of time to update.

Then I don't believe we actually have an argument here.

Create the PEP with the rationale (written in terms a non-web-specialist can understand) and the deprecation strategy, and we can consider adding the initial deprecation warning in 3.5 next year. So, no rush on getting the PEP together :)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list