On 24 Nov 2015 8:12 pm, "Paul Moore" <p.f.moore@gmail.com> wrote:
> On 24 November 2015 at 03:46, Nick Coghlan <ncoghlan@gmail.com> wrote:
> > I think there are three relevant categories here:
> >
> > 1. Folks who assume that "https" means the same thing in Python that
> > it means in web browsers, and are currently experiencing a silent
> > security failure
> > 2. Folks who already know it doesn't, and are relying on that to keep
> > their infrastructure working
> > 3. Folks currently in group 2 who would like to improve their
> > infrastructure to default to verifying certificates
> I'm not directly interested in this PEP (any code I write that is
> relevant will run on Windows) but there's another group:
> 4. People who use https because it's the published API, but are only
> looking at internal systems (where the threat window is minimised) and
> the internal infrastructure is out of their control but insecure.
> Browser users and other apps have to go through pain to work
> (accepting self-signed certs, repeatedly responding "Yes" to security
> warnings). Python code written for internal use just works at the
> moment. Maybe it "shouldn't", in some abstract sense, but it *does*
> and that is important to users.
> This group may know that they are taking risks, and may want to
> improve the infrastructure, but they *can't*. And this change breaks
> their apps (possibly in ways they can't fix easily - not all client
> environments offer ways to add trust, there's a reason tools like wget
> have "ignore certificate checks" flags even though everyone knows they
> are a bad idea).

I believe you're referring mainly to the original PEP 476 change there. In the context of PEP 493, this is another group that would potentially benefit from the suggested "security downgrade" environment variable (if any redistributors decide to implement that - RHEL doesn't as yet), since it would provide a way to restore the old behaviour without changing their client code or monkeypatching the SSL module as described in PEP 476.