> Traceback (most recent call last):
> File "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/threading.py",
> line 486, in __bootstrap_inner
> self.run()
> File
> "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_ssl.py",
> line 144, in run
> cert_reqs=self.server.certreqs)
> File "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/ssl.py",
> line 98, in __init__
> cert_reqs, ssl_version, ca_certs)
> sslerror: _ssl.c:271: SSL_CTX_use_PrivateKey_file error
Neal, I'm looking at why we're getting such opaque error messages, and
I see that _ssl.c uses a static PyErrorObject that gets created when
the module is initialized:
PySSLErrorObject = PyErr_NewException("socket.sslerror",
PySocketModule.error,
NULL);
Is this good style? It should be thread-safe, as the GIL is held while
the error is being returned to the calling code, but still...
Some of the code sets the error string in this directly before
returning NULL, and other pieces of the code call PySSL_SetError,
which creates the error string. I think some of the places which set
the string directly probably shouldn't; instead, they should call
PySSL_SetError to cons up the error name directly from the err code.
However, PySSL_SetError only works after the construction of an ssl
object, which means it can't be used there... I'll take a longer look
at it and see if there's a reasonable fix.
Bill
_______________________________________________
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
