[Python-Dev] Enable Hostname and Certificate Chain Validation

[Nick Coghlan]

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