On Jan 22, 2014, at 6:58 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 22 January 2014 21:36, Donald Stufft <don...@stufft.io> wrote: >> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg <m...@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. > > Regards, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
