[Python-Dev] Enable Hostname and Certificate Chain Validation
donald at stufft.io
Wed Jan 22 13:15:47 CET 2014
On Jan 22, 2014, at 6:58 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.
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.
> 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).
Do you really think those people would be making the same complaints
if they could restore the previous behavior with a simple boolean flag
delivered either via environment variable or in their own code?
> 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).
Every Python application *that depends on an invalid certificate* and is
written for Python3. It’s not hardly every Python application since a
good majority of them will simply continue working, and given that
most Python applications are still written for Python2 it’s not even
something that is going to affect the bulk of *Python* applications.
> 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.
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Python-Dev