[Python-Dev] Proposal for better SSL errors

Antoine Pitrou solipsis at pitrou.net
Sun May 27 01:23:48 CEST 2012


On Sat, 26 May 2012 17:44:08 -0400
Terry Reedy <tjreedy at udel.edu> wrote:
> > Traceback (most recent call last):
> > [...]
> > ssl.SSLError: [Errno 5] [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> > verify failed (_ssl.c:494) [88296 refs]
> 
> Repeating the same reason in upper and lower case is unhelpful noise. 
> Here is my suggested human-readable message.
> 
> ssl.SSLError: in ssl sublibrary, certificate verify failed

I should have made clearer that "certificate verify failed" is a
string returned by OpenSSL. In this case it's exactly similar to the
mnemonic, which might not always be the case (I honestly have not done
any research on this point). Also, the mnemonic is useful to know which
reason to test for, when seen in a traceback.

(here I'd draw a parallel with POSIX errnos, where it has been a common
request for years for OSError's str() to display the errno mnemonic,
such as e.g. ENOENT, rather than its number)

> >>>> e = sys.last_value
> >>>> e.library
> > 'SSL'
> 
> Not being up on ssl sublibraries, I would tend to think that means the 
> main ssl library that gets imported. If that is wrong, .sublibrary would 
> be clearer to me, but knowledgable users may be fine with it as it is.

Well, it's called "library" in OpenSSL-speak, so I kept that name, but
I am not particularly attached to it, so "sublibrary" could work too.

As for what it means, "SSL" refers to the implementation of the SSL
network protocol (or TLS), while other OpenSSL "libraries" cater with
e.g. certificate management ("X509"), parsing of certificate files
("PEM"), etc.

> > You'll note there is still a "Errno 5" in that error message; I don't
> > really know what to do with it. Hard-wiring the errno attribute to
> > something like None *might* break existing software, although that
> > would be unlikely since the current errno value is quite meaningless
> > and confusing (it has nothing to do with POSIX errnos).
> 
> Given what you have written, I think the aim should be to get rid of it. 

I also think it's desireable.

Thanks for sharing your opinion

Antoine.




More information about the Python-Dev mailing list