On Jun 3, 2013, at 6:01 PM, Paul Moore <p.f.moore@gmail.com> wrote:


On 3 June 2013 22:46, Donald Stufft <donald@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