[Python-Dev] Enable Hostname and Certificate Chain Validation
Nick Coghlan
ncoghlan at gmail.com
Wed Jan 22 12:58:10 CET 2014
More information about the Python-Dev mailing list
Wed Jan 22 12:58:10 CET 2014
- Previous message: [Python-Dev] Enable Hostname and Certificate Chain Validation
- Next message: [Python-Dev] Enable Hostname and Certificate Chain Validation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Enable Hostname and Certificate Chain Validation
- Next message: [Python-Dev] Enable Hostname and Certificate Chain Validation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list