Re: [Python-Dev] Other SSL issues in the tracker have been marked
> This occurs on at least 3 of the buildbots (ubuntu and debian on ia64, > ppc, and hppa). Here's one example: Unfortunately, I don't have Ubuntu or Debian machines. But I'd bet it's a variation in the specific version of OpenSSL being used. I just tested on Fedora Core 7, though, and test_ssl runs fine there. What version of OpenSSL is being used on the buildbots? Can I log into one of them and look at the configuration? > This also looks like it's not working on windows, but there is no info > from here: > http://python.org/dev/buildbot/all/x86%20XP-3%20trunk/builds/164/step-test/0 > > Other than: > test_ssl > The system cannot find the path specified. This must be the call to os.system in test_ssl.py:create_cert_files(). It's very UNIX-y. Can any bi-platform folks suggest a good alternative to os.system( "openssl req -batch -new -x509 -days 10 -nodes -config %s " "-keyout \"%s\" -out \"%s\" > /dev/null < /dev/null 2>&1" % (conffile, crtfile, crtfile)) that would be more Windows-friendly? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
> This occurs on at least 3 of the buildbots (ubuntu and debian on ia64, > ppc, and hppa). Here's one example: > > http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/832/step-test/0 If I'm reading this right, it's passing tests on "amd64 gentoo trunk", "x86 gentoo trunk", "g4 osx.4 trunk" (no surprise there). And looking at the community buildbots, it works on "x86 Redhat 9", "x86 Debian unstable", "amd64 Ubuntu gutsy", "G5 OS X", and so on. I've tested it myself on FC 7 and it works. And looking at the "ppc Debian unstable" case, test_socket is also failing there, so the test_ssl failure is not a big surprise. I'm not familiar with what's in Debian "trunk" or Ubuntu "trunk"; any idea what version of OpenSSL they have in them? But I think this exposes a more generic bug in test_ssl.py, which is that the server thread doesn't die when one of these failures occurs. It probably should. I'll make a patch -- but I don't have a system that this fails on, how will I test it? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
On 8/26/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > This occurs on at least 3 of the buildbots (ubuntu and debian on ia64, > > ppc, and hppa). Here's one example: > > > > http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/832/step-test/0 > > If I'm reading this right, it's passing tests on "amd64 gentoo trunk", > "x86 gentoo trunk", "g4 osx.4 trunk" (no surprise there). > > And looking at the community buildbots, it works on "x86 Redhat 9", > "x86 Debian unstable", "amd64 Ubuntu gutsy", "G5 OS X", and so on. > I've tested it myself on FC 7 and it works. > > And looking at the "ppc Debian unstable" case, test_socket is also > failing there, so the test_ssl failure is not a big surprise. > > I'm not familiar with what's in Debian "trunk" or Ubuntu "trunk"; any > idea what version of OpenSSL they have in them? For ia64 http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/833/step-test/0 [EMAIL PROTECTED]:~$ openssl version OpenSSL 0.9.8b 04 May 2006 I have access to some of the machines but not all of them. All of these run inside a chroot which might be causing a problem. I remember some issues with getting socket stuff to work right on them. But that was over a year ago and I don't remember the details now. :-( svn/google probably knows if you want to trawl through checkins. I'm not sure that will help much though. On this machines I was able to successfully make a key. That's why I'm thinking it might be some strange socket issue. > But I think this exposes a more generic bug in test_ssl.py, which is > that the server thread doesn't die when one of these failures occurs. > It probably should. I'll make a patch -- but I don't have a system > that this fails on, how will I test it? Yeah, I know this is difficult. Hopefully someone with WIndows will step up to help. We can at least make the test more robust and verify the files exist and are non-zero in size. I will do that now. At least the it shouldn't cause the test to time out. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
> But I think this exposes a more generic bug in test_ssl.py, which is
> that the server thread doesn't die when one of these failures occurs.
> It probably should. I'll make a patch -- but I don't have a system
> that this fails on, how will I test it?
Here's a patch which makes test_ssl a better player in the buildbots
environment. I deep-ended on "try-except-else" clauses.
Should I post this as an issue to the Tracker?
Bill
Index: Lib/ssl.py
===
--- Lib/ssl.py (revision 57506)
+++ Lib/ssl.py (working copy)
@@ -100,12 +100,13 @@
# see if it's connected
try:
socket.getpeername(self)
-# yes
+except:
+# no, no connection yet
+self._sslobj = None
+else:
+# yes, create the SSL object
self._sslobj = _ssl.sslwrap(self._sock, 0, keyfile, certfile,
cert_reqs, ssl_version, ca_certs)
-except:
-# no
-self._sslobj = None
self.keyfile = keyfile
self.certfile = certfile
self.cert_reqs = cert_reqs
Index: Lib/test/test_ssl.py
===
--- Lib/test/test_ssl.py(revision 57506)
+++ Lib/test/test_ssl.py(working copy)
@@ -91,38 +91,66 @@
def testTLSecho (self):
s1 = socket.socket()
-s1.connect(('127.0.0.1', 10024))
-c1 = ssl.sslsocket(s1, ssl_version=ssl.PROTOCOL_TLSv1)
-indata = "FOO\n"
-c1.write(indata)
-outdata = c1.read()
-if outdata != indata.lower():
-sys.stderr.write("bad data <<%s>> received\n" % data)
-c1.close()
+try:
+s1.connect(('127.0.0.1', 10024))
+except:
+sys.stdout.write("connection failure:\n" + string.join(
+traceback.format_exception(*sys.exc_info(
+raise test_support.TestFailed("Can't connect to test server")
+else:
+try:
+c1 = ssl.sslsocket(s1, ssl_version=ssl.PROTOCOL_TLSv1)
+except:
+sys.stdout.write("SSL handshake failure:\n" + string.join(
+traceback.format_exception(*sys.exc_info(
+raise test_support.TestFailed("Can't SSL-handshake with test
server")
+else:
+if not c1:
+raise test_support.TestFailed("Can't SSL-handshake with
test server")
+indata = "FOO\n"
+c1.write(indata)
+outdata = c1.read()
+if outdata != indata.lower():
+raise test_support.TestFailed("bad data <<%s>> received;
expected <<%s>>\n" % (data, indata.lower()))
+c1.close()
def testReadCert(self):
s2 = socket.socket()
-s2.connect(('127.0.0.1', 10024))
-c2 = ssl.sslsocket(s2, ssl_version=ssl.PROTOCOL_TLSv1,
- cert_reqs=ssl.CERT_REQUIRED, ca_certs=CERTFILE)
-cert = c2.getpeercert()
-if not cert:
-raise test_support.TestFailed("Can't get peer certificate.")
-if not cert.has_key('subject'):
-raise test_support.TestFailed(
-"No subject field in certificate: %s." %
-pprint.pformat(cert))
-if not (cert['subject'].has_key('organizationName')):
-raise test_support.TestFailed(
-"No 'organizationName' field in certificate subject: %s." %
-pprint.pformat(cert))
-if (cert['subject']['organizationName'] !=
- "Python Software Foundation"):
-raise test_support.TestFailed(
-"Invalid 'organizationName' field in certificate subject; "
-"should be 'Python Software Foundation'.");
-c2.close()
+try:
+s2.connect(('127.0.0.1', 10024))
+except:
+sys.stdout.write("connection failure:\n" + string.join(
+traceback.format_exception(*sys.exc_info(
+raise test_support.TestFailed("Can't connect to test server")
+else:
+try:
+c2 = ssl.sslsocket(s2, ssl_version=ssl.PROTOCOL_TLSv1,
+ cert_reqs=ssl.CERT_REQUIRED,
ca_certs=CERTFILE)
+except:
+sys.stdout.write("SSL handshake failure:\n" + string.join(
+traceback.format_exception(*sys.exc_info(
+raise test_support.TestFailed("Can't SSL-handshake with test
server")
+else:
+if not c2:
+raise test_support.TestFailed("Can't SSL-handshake with
test server")
+cert = c2.getpeercert()
+if not cert:
+raise test_support.TestFailed("Can't get peer
certificate."
Re: [Python-Dev] Other SSL issues in the tracker have been marked
No need, I've submitted this for you. Fingers crossed.
On 8/26/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > But I think this exposes a more generic bug in test_ssl.py, which is
> > that the server thread doesn't die when one of these failures occurs.
> > It probably should. I'll make a patch -- but I don't have a system
> > that this fails on, how will I test it?
>
> Here's a patch which makes test_ssl a better player in the buildbots
> environment. I deep-ended on "try-except-else" clauses.
>
> Should I post this as an issue to the Tracker?
>
> Bill
>
> Index: Lib/ssl.py
> ===
> --- Lib/ssl.py (revision 57506)
> +++ Lib/ssl.py (working copy)
> @@ -100,12 +100,13 @@
> # see if it's connected
> try:
> socket.getpeername(self)
> -# yes
> +except:
> +# no, no connection yet
> +self._sslobj = None
> +else:
> +# yes, create the SSL object
> self._sslobj = _ssl.sslwrap(self._sock, 0, keyfile, certfile,
> cert_reqs, ssl_version, ca_certs)
> -except:
> -# no
> -self._sslobj = None
> self.keyfile = keyfile
> self.certfile = certfile
> self.cert_reqs = cert_reqs
> Index: Lib/test/test_ssl.py
> ===
> --- Lib/test/test_ssl.py(revision 57506)
> +++ Lib/test/test_ssl.py(working copy)
> @@ -91,38 +91,66 @@
> def testTLSecho (self):
>
> s1 = socket.socket()
> -s1.connect(('127.0.0.1', 10024))
> -c1 = ssl.sslsocket(s1, ssl_version=ssl.PROTOCOL_TLSv1)
> -indata = "FOO\n"
> -c1.write(indata)
> -outdata = c1.read()
> -if outdata != indata.lower():
> -sys.stderr.write("bad data <<%s>> received\n" % data)
> -c1.close()
> +try:
> +s1.connect(('127.0.0.1', 10024))
> +except:
> +sys.stdout.write("connection failure:\n" + string.join(
> +traceback.format_exception(*sys.exc_info(
> +raise test_support.TestFailed("Can't connect to test server")
> +else:
> +try:
> +c1 = ssl.sslsocket(s1, ssl_version=ssl.PROTOCOL_TLSv1)
> +except:
> +sys.stdout.write("SSL handshake failure:\n" + string.join(
> +traceback.format_exception(*sys.exc_info(
> +raise test_support.TestFailed("Can't SSL-handshake with test
> server")
> +else:
> +if not c1:
> +raise test_support.TestFailed("Can't SSL-handshake with
> test server")
> +indata = "FOO\n"
> +c1.write(indata)
> +outdata = c1.read()
> +if outdata != indata.lower():
> +raise test_support.TestFailed("bad data <<%s>> received;
> expected <<%s>>\n" % (data, indata.lower()))
> +c1.close()
>
> def testReadCert(self):
>
> s2 = socket.socket()
> -s2.connect(('127.0.0.1', 10024))
> -c2 = ssl.sslsocket(s2, ssl_version=ssl.PROTOCOL_TLSv1,
> - cert_reqs=ssl.CERT_REQUIRED, ca_certs=CERTFILE)
> -cert = c2.getpeercert()
> -if not cert:
> -raise test_support.TestFailed("Can't get peer certificate.")
> -if not cert.has_key('subject'):
> -raise test_support.TestFailed(
> -"No subject field in certificate: %s." %
> -pprint.pformat(cert))
> -if not (cert['subject'].has_key('organizationName')):
> -raise test_support.TestFailed(
> -"No 'organizationName' field in certificate subject: %s." %
> -pprint.pformat(cert))
> -if (cert['subject']['organizationName'] !=
> - "Python Software Foundation"):
> -raise test_support.TestFailed(
> -"Invalid 'organizationName' field in certificate subject; "
> -"should be 'Python Software Foundation'.");
> -c2.close()
> +try:
> +s2.connect(('127.0.0.1', 10024))
> +except:
> +sys.stdout.write("connection failure:\n" + string.join(
> +traceback.format_exception(*sys.exc_info(
> +raise test_support.TestFailed("Can't connect to test server")
> +else:
> +try:
> +c2 = ssl.sslsocket(s2, ssl_version=ssl.PROTOCOL_TLSv1,
> + cert_reqs=ssl.CERT_REQUIRED,
> ca_certs=CERTFILE)
> +except:
> +sys.stdout.write("SSL handshake failure:\n" + string.join(
> +traceback.format_exception(*sys.exc_info(
> +raise test_support.TestFailed("Can't
Re: [Python-Dev] Other SSL issues in the tracker have been marked
> Yeah, I know this is difficult. Hopefully someone with WIndows will > step up to help. We can at least make the test more robust and verify > the files exist and are non-zero in size. I will do that now. At > least the it shouldn't cause the test to time out. Yes, the patch I sent out should fix that. I'd like to know, for the machines where the test is failing, what's in the generated cert file -- should be an RSA PRIVATE KEY and a CERTIFICATE -- and what order they occur in. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
Well, as long as you have your ears on, here's another patch to test_ssl.
1) Fixes the bug that two class names are initial-lower-case.
2) Replaces the poll waiting for the server to become ready with
a threading.Event signal.
Bill
Index: Lib/test/test_ssl.py
===
--- Lib/test/test_ssl.py(revision 57521)
+++ Lib/test/test_ssl.py(working copy)
@@ -153,9 +153,9 @@
c2.close()
-class threadedEchoServer(threading.Thread):
+class ThreadedEchoServer(threading.Thread):
-class connectionHandler(threading.Thread):
+class ConnectionHandler(threading.Thread):
def __init__(self, server, connsock):
self.server = server
@@ -219,6 +219,7 @@
self.certreqs = certreqs
self.cacerts = cacerts
self.sock = socket.socket()
+self.flag = None
if hasattr(socket, 'SO_REUSEADDR'):
self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
if hasattr(socket, 'SO_REUSEPORT'):
@@ -228,15 +229,22 @@
threading.Thread.__init__(self)
self.setDaemon(False)
+def start (self, flag=None):
+self.flag = flag
+threading.Thread.start(self)
+
def run (self):
self.sock.settimeout(0.5)
self.sock.listen(5)
self.active = True
+if self.flag:
+# signal an event
+self.flag.set()
while self.active:
try:
newconn, connaddr = self.sock.accept()
#sys.stdout.write('\nserver: new connection from ' +
str(connaddr) + '\n')
-handler = self.connectionHandler(self, newconn)
+handler = self.ConnectionHandler(self, newconn)
handler.start()
except socket.timeout:
pass
@@ -337,9 +345,11 @@
server = None
if test_support.is_resource_enabled('network'):
-server = threadedEchoServer(10024, CERTFILE)
-server.start()
-time.sleep(1)
+server = ThreadedEchoServer(10024, CERTFILE)
+flag = threading.Event()
+server.start(flag)
+# wait for it to start
+flag.wait()
tests.append(ConnectedTests)
thread_info = test_support.threading_setup()
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
Thanks. I applied it. -- n
On 8/26/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Well, as long as you have your ears on, here's another patch to test_ssl.
>
> 1) Fixes the bug that two class names are initial-lower-case.
>
> 2) Replaces the poll waiting for the server to become ready with
> a threading.Event signal.
>
> Bill
>
> Index: Lib/test/test_ssl.py
> ===
> --- Lib/test/test_ssl.py(revision 57521)
> +++ Lib/test/test_ssl.py(working copy)
> @@ -153,9 +153,9 @@
> c2.close()
>
>
> -class threadedEchoServer(threading.Thread):
> +class ThreadedEchoServer(threading.Thread):
>
> -class connectionHandler(threading.Thread):
> +class ConnectionHandler(threading.Thread):
>
> def __init__(self, server, connsock):
> self.server = server
> @@ -219,6 +219,7 @@
> self.certreqs = certreqs
> self.cacerts = cacerts
> self.sock = socket.socket()
> +self.flag = None
> if hasattr(socket, 'SO_REUSEADDR'):
> self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> if hasattr(socket, 'SO_REUSEPORT'):
> @@ -228,15 +229,22 @@
> threading.Thread.__init__(self)
> self.setDaemon(False)
>
> +def start (self, flag=None):
> +self.flag = flag
> +threading.Thread.start(self)
> +
> def run (self):
> self.sock.settimeout(0.5)
> self.sock.listen(5)
> self.active = True
> +if self.flag:
> +# signal an event
> +self.flag.set()
> while self.active:
> try:
> newconn, connaddr = self.sock.accept()
> #sys.stdout.write('\nserver: new connection from ' +
> str(connaddr) + '\n')
> -handler = self.connectionHandler(self, newconn)
> +handler = self.ConnectionHandler(self, newconn)
> handler.start()
> except socket.timeout:
> pass
> @@ -337,9 +345,11 @@
>
> server = None
> if test_support.is_resource_enabled('network'):
> -server = threadedEchoServer(10024, CERTFILE)
> -server.start()
> -time.sleep(1)
> +server = ThreadedEchoServer(10024, CERTFILE)
> +flag = threading.Event()
> +server.start(flag)
> +# wait for it to start
> +flag.wait()
> tests.append(ConnectedTests)
>
> thread_info = test_support.threading_setup()
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
Now it looks as if both the Debian and Ubuntu failures are failing because they can't create a certificate, just like the Windows test. I'll go out on a limb here and guess that it's because "openssl" isn't on the path of the user running the tests. That would also account for the other stack traces, if the keyfile or certfile didn't actually contain a key or a cert. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
Here's a patch that will turn the buildbots green, by not trying the
connected tests if the certificate can't be created. It also shows
the created cert if run in verbose mode.
We still need a working os.system command for Windows.
Bill
Index: Lib/test/test_ssl.py
===
--- Lib/test/test_ssl.py(revision 57534)
+++ Lib/test/test_ssl.py(working copy)
@@ -194,7 +194,8 @@
self.server.stop()
self.running = False
else:
-#sys.stdout.write("\nserver: %s\n" %
msg.strip().lower())
+if test_support.verbose:
+sys.stdout.write("\nserver: %s\n" %
msg.strip().lower())
sslconn.write(msg.lower())
except ssl.sslerror:
sys.stdout.write("Test server failure:\n" + string.join(
@@ -243,7 +244,8 @@
while self.active:
try:
newconn, connaddr = self.sock.accept()
-#sys.stdout.write('\nserver: new connection from ' +
str(connaddr) + '\n')
+if test_support.verbose:
+sys.stdout.write('\nserver: new connection from ' +
str(connaddr) + '\n')
handler = self.ConnectionHandler(self, newconn)
handler.start()
except socket.timeout:
@@ -322,19 +324,21 @@
(conffile, crtfile, crtfile))
# now we have a self-signed server cert in crtfile
os.unlink(conffile)
-if error or not os.path.exists(crtfile) or os.path.getsize(crtfile) == 0:
-raise test_support.TestFailed(
-"Unable to create certificate for test %d." % error)
-return d, crtfile
+if (error or
+(not os.path.exists(crtfile)) or
+(os.path.getsize(crtfile) == 0)):
+if test_support.verbose:
+sys.stdout.write("\nUnable to create certificate for test. "
+ "Error status %d.\n" % (error >> 8))
+shutil.rmtree(d)
+return None, None
+else:
+if test_support.verbose:
+sys.stdout.write(open(crtfile, 'r').read() + '\n')
+return d, crtfile
-# XXX(nnorwitz): should this code be removed now?
-#sf_certfile = os.path.join(d, "sourceforge-imap.pem")
-#sf_cert = ssl.fetch_server_certificate('pop.gmail.com', 995)
-#open(sf_certfile, 'w').write(sf_cert)
-#return d, crtfile, sf_certfile
-# sys.stderr.write(open(crtfile, 'r').read() + '\n')
-def test_main():
+def test_main(verbose=False):
if skip_expected:
raise test_support.TestSkipped("socket module has no ssl support")
@@ -344,13 +348,16 @@
tests = [BasicTests]
server = None
-if test_support.is_resource_enabled('network'):
+if CERTFILE and test_support.is_resource_enabled('network'):
server = ThreadedEchoServer(10024, CERTFILE)
flag = threading.Event()
server.start(flag)
# wait for it to start
flag.wait()
tests.append(ConnectedTests)
+else:
+if test_support.verbose:
+sys.stdout.write("\nSkipping test_ssl ConnectedTests; couldn't
create a certificate.\n")
thread_info = test_support.threading_setup()
@@ -362,7 +369,8 @@
# wait for it to stop
server.join()
-shutil.rmtree(tdir)
+if tdir and os.path.isdir(tdir):
+shutil.rmtree(tdir)
test_support.threading_cleanup(*thread_info)
if __name__ == "__main__":
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
apt-get install openssl will fix that on those systems. on windows you're unlikely to ever have an openssl binary present and available to execute. On 8/26/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > Now it looks as if both the Debian and Ubuntu failures are failing > because they can't create a certificate, just like the Windows test. > I'll go out on a limb here and guess that it's because "openssl" isn't > on the path of the user running the tests. > > That would also account for the other stack traces, if the keyfile > or certfile didn't actually contain a key or a cert. > > Bill > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
