On 05.04.2015 18:28, Donald Stufft wrote:
> 
> Donald Stufft added the comment:
> 
>> Now, I knew how to fix this, but the solution was not
>> an obvious one. I had to use truss to figure out where OpenSSL
>> was looking for certificates and the added the Mozilla cert
>> bundle from our egenix-pyopenssl package to make things work
>> again.
> 
> You also could have passed the --cert flag to pip to tel pip specifically where
> to look for them (also available via environment variable and config file)
> though I'm guessing it wasn't actually pip itself that had a problem because
> we ship our own CA file and we don't actually rely on the stdlib to have
> validated TLS. Unless you were using an old pip I guess.

I was working on a Zope installation using zc.buildout, so
basically setuptools, and yes, it was an older version as well.

But this is only an example of an application not working anymore
because the system's OpenSSL could not verify certificates.
In this case, no root CA certs were available. On older systems
with proper root CA certs, it's likely that the newer CA certs
needed to verify the PyPI certificates are not installed...
and yes: those system do exist and are in active use, simply because
they cannot be upgraded for other reasons :-)

>> Again: Please let the users decide what level of security they
>> want to apply. We can point users to solutions, but in the end
>> have to respect their own decisions. Note that staying with
>> Python 2.7.8 is a much worse approach than disabling the checks.
> 
> Sure, and nobody has ever advocated to make it impossible to disable the TLS
> verification. For me it's entirely about the scope of the setting. I don't
> think that a Python wide setting is the right scope. That's a knob that has
> an extremely large scope of which end users are most likely not going to be
> completely aware of the total impact of adjusting that knob. This isn't even
> something that they could reasonably audit their system with _today_ and then
> say "OK I've looked at everything that uses Python and I'm happy for it not to
> verify" because if they every install anything else that uses Python (whether
> they know it uses Python or not) they have to re-evaluate that decision they
> made all over again, but with no indicator that they need to do that.

I'd be fine with having a knob that says: don't check the certificates
but warn me about instances where the certificates are not checked
(using the warning framework).