[Python-Dev] Looking for volunteers to test Tulip on Windows (original) (raw)

Guido van Rossum guido at python.org
Sat Oct 19 00:56:42 CEST 2013

Thanks! That's probably fine for now -- it means the standard library doesn't know where the root certificates are. We had a huge discussion about this over on python-tulip: https://groups.google.com/forum/#!topic/python-tulip/c_lqdFjPEbE

TL;DR: The stdlib openssl wrapper ought to know where each platform stores its root certificates and automatically use them, but it currently doesn't always. Users who really don't care but still want to use SSL must create an SSL context with verify_mode set to ssl.CERT_NONE (and live with the risk, obviously). This stuff passes on OS X only because there's a system openssl library that always uses the system root certificates.

If anyone can help fixing the ssl.py module (or the _ssl extension) so that sslcontext.set_default_verify_paths() uses the system root certs on Windows that would be a huge help. (I have tried this on an Ubuntu box too, and there it actually works.)

On Fri, Oct 18, 2013 at 3:42 PM, Richard Oudkerk <shibturn at gmail.com> wrote:

On 18/10/2013 10:37pm, Guido van Rossum wrote:

Good sleuthing! Does the attached patch fix it?

(Off-topic: the code is pretty inconsistent about catching BaseException. Maybe it shouldn't be caught at all?) It fixes it in the sense of printing a sensible traceback;-) $ PYTHONPATH='c:/Repos/tulip' /c/Repos/cpython-33/PCbuild/**python fetch3.py http://dropbox.com -v * Connecting to dropbox.com:80 using tcp * dropbox.com resolves to 108.160.165.62, 108.160.166.62, 199.47.216.179, 199.47.217.179 * New connection ('108.160.165.62', 80, False) * Connected to ('108.160.165.62', 80) > GET / HTTP/1.1 > Host: dropbox.com > < HTTP/1.1 301 Moved Permanently_ _< Server: nginx_ _< Date: Fri, 18 Oct 2013 22:40:13 GMT_ _< Content-Type: text/html_ _< Content-Length: 178_ _< Connection: keep-alive_ _< Location: https://dropbox.com/_ _<_ _redirect to https://dropbox.com/_ _* Connecting to dropbox.com:443 using ssl_ _* dropbox.com resolves to 108.160.165.62, 108.160.166.62, 199.47.216.179,_ _199.47.217.179_ _Traceback (most recent call last):_ _File "fetch3.py", line 211, in main() File "fetch3.py", line 206, in main body = loop.rununtilcomplete(fetch(**sys.argv[1], '-v' in sys.argv)) File "c:\Repos\tulip\asyncio\base**events.py", line 177, in rununtilcomplete return future.result() File "c:\Repos\tulip\asyncio**futures.py", line 221, in result raise self.exception File "c:\Repos\tulip\asyncio\tasks.**py", line 257, in step result = coro.throw(exc) File "fetch3.py", line 192, in fetch yield from request.connect(pool) File "fetch3.py", line 80, in connect ssl=self.ssl) File "fetch3.py", line 36, in openconnection reader, writer = yield from openconnection(host, port, ssl=ssl) File "c:\Repos\tulip\asyncio**streams.py", line 41, in openconnection lambda: protocol, host, port, **kwds) File "c:\Repos\tulip\asyncio\base**events.py", line 356, in createconnection yield from waiter File "c:\Repos\tulip\asyncio**futures.py", line 318, in iter yield self # This tells Task to wait for completion. File "c:\Repos\tulip\asyncio\tasks.**py", line 308, in wakeup value = future.result() File "c:\Repos\tulip\asyncio**futures.py", line 221, in result raise self.exception File "c:\Repos\tulip\asyncio**selectorevents.py", line 579, in onhandshake self.sock.dohandshake() File "C:\Repos\cpython-33\lib\ssl.**py", line 520, in dohandshake self.sslobj.dohandshake() ssl.SSLError: [SSL: CERTIFICATEVERIFYFAILED] certificate verify failed (ssl.c:553) -- Richard

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131018/faf02889/attachment.html>

More information about the Python-Dev mailing list