On Jun 3, 2013, at 6:01 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 3 June 2013 22:46, Donald Stufft <don...@stufft.io> wrote: >> Also, we should consider the issue for application users. Suppose I'm using >> a Python application that downloads something from the web. I upgrade to >> 3.4, and the app stops working because of a "will cease to work" case. As an >> end user, how can I get the app working again? Having to patch the sources >> isn't an option, and reverting to 3.3 provokes the reaction "Python broke my >> app". > > Supply a SSL vert using the environment variable? > > Hmm, that would be acceptable, I guess, for many users (although Windows > users are somewhat more environment-variable-averse than Unix users). But you > say that as if it's obvious how to do that (or where to get a cert). It's > certainly not obvious to me, and if "it works in Internet Explorer", I'd have > no idea where to get a cert from that I could use in an environment variable. > > Just to repeat - I agree with the principle, but in many environments, users > are pretty much clueless about security and actively object to being educated > "for their own safety". These users will disable all security quite happily > if it stops the internal app failing, and will blame Python for "making > things harder" and breaking backward compatibility. On the other hand, I > suspect we're talking about an extremely low percentage of cases, so let's > not blow the issue out of proportion :-) > > Paul
Let me make myself a bit more clear because maybe I haven't been.
If someone is relying on the insecure by default behavior and Python 3.4 gets
this change, their code will break and their options will be:
Client side:
- Disable Verification, essentially reverting back to the old behavior.
- Setup their Python install to be able to validate that certificate
- This may be importing it into their OS certificate store
- This may be using an env var to specify
- This may be passing it directly somewhere
Server side:
- Make the certificate valid
- Purchase a Valid by default certificate
- Serve immedaries etc.
Generally any of these will be completely valid options, even disabling the
checks. The idea behind my proposal is that people generally only use TLS for a
reason and that reason is they want to protect against the kinds of attacks
that TLS protects against. You really only get the bulk of those protections if
you validate the certificates. So for the vast bulk of people validation is the
option they want. It also happens that validation on by default is "secure" by
default which aims a fairly large foot gun away from peoples feet.
To expand on something else, I'm completely willing to do whatever I can to hep
make this happen. I don't really know what the process is. If I need to write a
PEP I'll do that. If I need to volunteer to manage the certificates, I'll do
that. If we need docs or tooling to help the people who this change might break
I'll do that too.
-----------------
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
