I've uploaded the source version of the backported SSL module to the
Cheeseshop. It would be nice to include Windows builds for it for
Python 2.3, 2.4, and 2.5, as well, and I'd be happy to upload them if
someone could create them.
http://pypi.python.org/pypi?name=sslversion=1.4:action=display
I found a bug -- setup.py wasn't detecting the difference between
2.5.0 and 2.5.1 properly. I've updated the release to 1.5.
http://pypi.python.org/pypi?name=sslversion=1.5;
Bill
___
Python-Dev mailing list
Python-Dev@python.org
I believe this is already fixed in 2.6 with the new SSL code (I got
the same error writing the unit tests and fixed it). Thanks for
reporting it, though.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
Well, it's an OS level difference and I thought that in general Python
*doesn't* try to protect you from OS differences.
I think that's the key point. In general, Python tries to present a
translucent interface to the OS in which OS differences can show
through, in contrast to other languages
I've posted an sdist version of the 'ssl' module for Pythons 2.3.5 to
2.5.x, at http://www.parc.com/janssen/transient/ssl-1.3.tar.gz. I think
this is 'gold master', but before I upload it to the Cheeseshop, I'd like
to get more testing on a broader variety of platforms.
The intent of this
I guess something we should think about is whether to introduce RFC
2818 hostname checking into urllib.urlopen() and similar utilities.
Presumably one would add an optional arg specifying a file full of
root certs to validate against, and if that arg was present, would
retrieve the hostname info
differentiation between between text files and binary files, a bad
idea introduced by Windows and perpetuated (apparently) by Python. I
can't believe this wasn't eliminated in py3k!
The binary/text distinction is being increased in Py3k rather than
reduced (the API for binary files
I've checked in the asyncore SSL patch, and the Windows buildbots are
failing on the HTTPS test. I believe it's due to this insane
differentiation between between text files and binary files, a bad
idea introduced by Windows and perpetuated (apparently) by Python. I
can't believe this wasn't
I've checked in the asyncore SSL patch, and the Windows buildbots are
failing on the HTTPS test.
Fixed.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I see that base64.b64encode and base64.standard_b64encode no longer
introduce line breaks into the output strings, as base64.encodestring
does. Shouldn't there be an option on one of them to do this?
See:
http://mail.python.org/pipermail/python-bugs-list/2001-October/
007856.html
I've now got an HTTPS server (more importantly, one built on asyncore
and SocketServer and BaseHTTPServer), running in the test suite.
Also, I think that, for the moment, I'm going to take
ssl.ssl_shutdown() out of the library. The state machine implemented
at the GoogleSprint really only does
Does anything in textwrap already do the trick? If not, that might
be the best place to refactor similar code to.
Yes, textwrap.fill. Thanks for pointing it out.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
In other words, both the standard and your extension module on Windows
bring along their own OpenSSL.
I see -- thanks.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Anyway, philosophy aside, I'll try to make some time in the next few
days to get a working setup.py for the SSL package using mingw.
Hopefully, Bill will then integrate this and we'll have mingw as a
supported option.
I'll be happy to do that!
Bill
However, there is an alternative to using multiple IP addresses:
one could also use multiple subject alternative names, and create
a certificate that lists them all.
Unfortunately, much of the client code that does the hostname
verification is wrapped up in gullible Web browsers or Java HTTPS
I see that base64.b64encode and base64.standard_b64encode no longer
introduce line breaks into the output strings, as base64.encodestring
does. Shouldn't there be an option on one of them to do this?
Bill
___
Python-Dev mailing list
I see that base64.b64encode and base64.standard_b64encode no longer
introduce line breaks into the output strings, as base64.encodestring
does. Shouldn't there be an option on one of them to do this?
See:
http://mail.python.org/pipermail/python-bugs-list/2001-October/007856.html
section 2.1
I could build some Windows installers if you want, but I'd need to
download and install some extra versions of Python, so you'd have to
tell me which you want doing (and I can't offer to commit to doing
this on a regular basis...)
Thanks, but let's wait till this settles down a bit (say, a
I can't figure out how to build a Windows package for ssl-1.1.tar.gz,
and probably don't have the tools to do it anyway. I presume that
both a Windows machine and Visual Studio (because there's a C
extension) is required?
Anyone out there who's interested in the challenge?
It's at
The SSL tests currently use SSL-protected ports on gmail.com and
Verisign for testing. That's not what they are for; I think we should
shift to using SSL-protected ports on python.org somewhere. Are there
any HTTPS servers, or SSL-protected POP or IMAP servers, currently
running on python.org
By the way, I think the hostname matching provisions of 2818 (which
is, after all, only an informational RFC, not a standard) are poorly
thought out. Many machines have more hostnames than you can shake a
stick at, and often provide certs with the wrong hostname in them
(usually because
Yes, port 443 on svn.python.org seems to work for this purpose.
Everyone OK with that? If so, I'll change the SSL test code.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Thanks, Mark (and David, who replied to me personally). I'll update
the setup.py files with your suggestions and do a 1.2 (with more
metadata in it, too). Looks like the functionality is working for
people, even if the build is still a bit flakey.
Bill
* find_ssl() is along way from working on Windows. Python itself uses magic
to locate an SSL directory in the main Python directory's parent. On my
system, this is c:\src\openssl-0.9.7e, but obviously that could be almost
anywhere, and with almost any name. See PCBuild\build_ssl.py and
Can't we look in the registry for this? We have a working Python;
perhaps we can just use a Windows-specific registry lookup to find
OpenSSL? (I'm just blue-skying here; I have no clue how things work
on Windows.)
Not really. Python itself, when building _ssl, doesn't look for a
Neal Norwitz and Ralf Grosse-Kunstleve have access to that
machine.
Neal's on leave all this month, I believe.
Well, I'm not sure it's urgent. Are there lots of Alphas still
running? And Tru64 is in end-of-life mode.
Bill
___
Python-Dev
I'm packaging up the SSL support for Python 2.3, and I'd like to be
able to include the unit test for it along with the package. Ideally,
I'd like to be able to say
% python setup.py build
% python setup.py test
and have the regrtest.py module run my tests. Any ideas (examples) of
how
It's actually not bad. I put the test code and the data files in a
test subdirectory of my distribution, then added the following to
the setup.py file:
class Test (Command):
user_options = []
def initialize_options(self):
pass
def finalize_options(self):
pass
I see that the setup.py at the top level of the Python distribution
does a lot of things wrt sensing compiler options, etc, that I'd like
to re-use in my SSL setup.py distribution file. I'm a bit curious
as to why this framework isn't in the distutils package?
Bill
I've put up an initial source package at
http://www.parc.com/janssen/transient/ssl-1.0.tar.gz which I've tested
with Python 2.3.5 on Mac OS X 10.4.10 (Intel) and Python 2.5 on Fedora
Core 7. Please send bugs you find to me at [EMAIL PROTECTED]
Try python setup.py build, then python setup.py
Looks like this change is bothering the error returns from my
backported SSL code. I believe this is only in 2.5.1 and later -- can
anyone confirm that?
Bill
r52906 | martin.v.loewis | 2006-12-03 03:23:45 -0800 (Sun, 03 Dec 2006) | 4
I've put up an initial source package at
http://www.parc.com/janssen/transient/ssl-1.0.tar.gz which I've tested
with Python 2.3.5 on Mac OS X 10.4.10 (Intel) and Python 2.5 on Fedora
Core 7. Please send bugs you find to me at [EMAIL PROTECTED]
Try python setup.py build, then python
One, what *is* the scope of your
amibition? I feel silly for asking, because I am pretty sure that
somewhere in the beginning of this thread I missed either a proposal, a
PEP reference, or a ticket number, but I've poked around a little and I
can't seem to find it. Can you provide a
I've now built a framework in test_ssl to test all client protocols
(SSL2, SSL3, SSL23, TLS1) against all server protocols, and here's
what I've come up with. Servers are along the X axis, and clients are
on the Y axis. Yes means that that client protocol can talk to that
server protocol.
Here's the updated connection table:
SSL2SSL3SS23TLS1
SSL2yes no yes no
SSL3yes yes yes no
SSL23 yes no yes no
TLS1no no yes yes
Given this, I think the client-side
The Alpha/Tru64 buildbot seems to be having difficulty compiling
the _ssl.c file. Looks like missing header files. Anyone know what
the configuration of OpenSSL on that machine is like?
Bill
___
Python-Dev mailing list
Python-Dev@python.org
The Solaris 10 buildbot is complaining about test_ssl, and I think
it's because some of the functions in it use constants from the ssl
module at the top level, i.e.,
def tryProtocolCombo (server_protocol,
client_protocol,
expectedToWork,
By the way, if you're offering to help with this, there are a couple
of things I could use some help with. I scratched my head a bit about
how to turn the othername possibility of a subjectAltName into a
Python data structure, using the OpenSSL C code, and finally gave up.
If you could provide a
The Solaris 10 buildbot is complaining about test_ssl, and I think
it's because some of the functions in it use constants from the ssl
module at the top level, i.e.,
def tryProtocolCombo (server_protocol,
client_protocol,
There are some functions in _ssl.c for gathering randomness from a
daemon, and adding that randomness to the pseudo-random number
generator in SSL, before using SSL. There's a note there saying that
on some platform this is necessary. Anyone know which platforms?
In general, anything
test_tcl fails on me (OS X 10.4.10 on an Intel Mac, remotely logged
in via SSH and X Windows):
That's no surprise, I would say: it seems you link against TkAqua
(not X11 Tk); for that to work, you need a reference to WindowServer,
which won't be available when logged in through SSL.
I'm looking for suggestions for other SSL module tests.
Here's the result of running my (not yet checked-in) test_ssl.py
module in verbose mode. I'm pretty happy with the codebase right now,
and barring other tests, I'm ready to check it in and start on the 3.x
patch (or perhaps the 2.3
Be convoluted yourself and do this:
#define PySSL_BEGIN_ALLOW_THREADS { if (_ssl_locks) { Py_BEGIN_ALLOW_THREADS
#define PySSL_END_ALLOW_THREADS Py_END_ALLOW_THREADS } }
(Untested, but I think it should work.)
Yes, that had occurred to me. We want the code inside the braces
still to run
I've now built a framework in test_ssl to test all client protocols
(SSL2, SSL3, SSL23, TLS1) against all server protocols, and here's
what I've come up with. Servers are along the X axis, and clients are
on the Y axis. Yes means that that client protocol can talk to that
server protocol.
This has got to be a problem with other extension modules linked to
libraries which have their own threading abstractions.
Sure enough, sqlite3 simply assumes threads (won't build without
them), and turns them on if it's used (by calling
PyThread_get_thread_ident(), which in turn calls
I can't seem to run the regression tests in a --without-threads build.
Might be interesting to configure a buildbot this way to keep
ourselves honest.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
I can't seem to run the regression tests in a --without-threads build.
Might be interesting to configure a buildbot this way to keep
ourselves honest.
Because regrtest.py was importing test_socket_ssl without catching the
ImportError exception:
% ./python.exe ./Lib/test/regrtest.py
Because regrtest.py was importing test_socket_ssl without catching the
ImportError exception:
If that is the reason you cannot run it, then it seems it works just
fine. There is nothing wrong with tests getting skipped.
It wasn't getting skipped, it was crashing the regression testing
There are some functions in _ssl.c for gathering randomness from a
daemon, and adding that randomness to the pseudo-random number
generator in SSL, before using SSL. There's a note there saying that
on some platform this is necessary. Anyone know which platforms?
Bill
test_tcl fails on me (OS X 10.4.10 on an Intel Mac, remotely logged
in via SSH and X Windows):
% test_tcl
2007-09-08 17:00:22.629 python.exe[4163] CFLog (0): CFMessagePort:
bootstrap_register(): failed 1100 (0x44c), port = 0x3a03, name =
'Processes-0.58327041'
See
I've been expanding the SSL test suite, and found something like this
cropping up, not always, but maybe 30% of the time. So I run it under
gdb, but the szone_error breakpoint never gets hit. Any other
malloc debugging tips I should know about?
(gdb) info break
Num Type Disp Enb
Is this a --with-pydebug build? If not, it should be.
Yes.
If that still does not give insights, I usually try valgrind
(although usually with little success).
Actually, Google is your friend here. The message in malloc is
misleading; set a breakpoint in malloc_printf instead.
Bill
I'm seeing a number of malloc (actully, free) errors, now that I'm
pounding on the OpenSSL server/client setup with lots of server
threads and client threads. They all look like either
(gdb) bt
#0 0x9010b807 in malloc_printf ()
#1 0x900058ad in szone_free ()
#2 0x90005588 in free ()
#3
I'm seeing a number of malloc (actully, free) errors, now that I'm
pounding on the OpenSSL server/client setup with lots of server
threads and client threads. They all look like either
The issue seems to be that we assume OpenSSL is thread-safe (that is,
we call Py_BEGIN_ALLOW_THREADS /
My analysis is that we need to add lock and unlock functions to the
OpenSSL initialization code we currently use
Yep, this seems to fix the problem. I'm now able to re-enable
Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS, and still get a clean
run:
(gdb) run
Starting program:
Reading through the C API documentation, I find:
``This is done so that dynamically loaded extensions compiled with
thread support enabled can be loaded by an interpreter that was
compiled with disabled thread support.''
I've currently got the set-up-SSL-threading code in _ssl.c surrounded
by a
#define SSL_ALLOW_THREADS {if (_ssl_locks != NULL) { Py_BEGIN_ALLOW_THREADS }}
#define SSL_DISALLOW_THREADS {if (_ssl_locks != NULL) {
Py_BEGIN_ALLOW_THREADS }}
I'd forgotten how convoluted Py_BEGIN_ALLOW_THREADS and
Py_END_ALLOW_THREADS were. Anyone have any other suggestions about
how to
So what happens when someone loads the _ssl module, initializes the
threads, and tries to use SSL? It's going to start failing again. I
Which turns out to be exactly what test_ssl.py does. I'm tempted
to have the _ssl module call PyEval_InitThreads(). Would that be kosher?
Bill
the Py_BEGIN_ALLOW_THREADS on SSL context
reads and writes.
On 9/7/07, Bill Janssen [EMAIL PROTECTED] wrote:
So what happens when someone loads the _ssl module, initializes the
threads, and tries to use SSL? It's going to start failing again. I
Which turns out to be exactly what test_ssl.py does. I'm tempted
I very much doubt that, at least if you want to report decoded
information. Conceptually, there is an infinite number of extensions,
and when you are done, I can show you lots of certificates that
have extensions that you don't support.
I'm not going to decode anything; I'm just using the
RFC 2818
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
By the way, I think the hostname matching provisions of 2818 (which
is, after all, only an informational RFC, not a standard) are poorly
thought out. Many machines have more hostnames than you can shake a
stick at, and often provide certs with the wrong hostname in them
(usually because they have
When you say the full DER form, are you simply referring to the full
blob, or a broken-down representation by key and by extension?
The full blob.
This begs the question: M2Crypto and PyOpenSSL already do what you're
proposing to do, as far as I can tell, and are, as you say, more
After a great deal of discussion, under the Subject line of frozenset
C API? (you may have missed it :-), I'm coming to the conclusion that
in revealing the fields of an SSL certificate, less is more.
From one of the messages in that thread:
I'm trying to give the application the ability to do
In any case, it certainly sounds to me as if there can be multiple
instances of AttributeTypeAndValue with the same type field in a
single Name. So I'll represent them as tuples, which will preserve
the order in which they occur in the certificate, and make the value
immutable.
Ok. I
The DNs of these are structurally different, one being
/DC=org/DC=python/CN=foo/CN=bar and the other
/DC=org/DC=python/CN=foo2+CN=bar2
Ah, I see what you're driving at.
You can inspect them yourself by looking at the certs with openssl:
% openssl x509 -text -in attachment-0002.crt
Certificate:
More succinctly:
% openssl x509 -subject -noout -in attachment-0002.crt
subject= /DC=org/DC=python/CN=foo/CN=bar
% openssl x509 -subject -noout -in attachment-0003.crt
subject= /DC=org/DC=python/CN=bar2/CN=foo2
%
Bill
___
Python-Dev mailing list
See the example certificates. If you get (('cn','a'),('email','b')),
you can't tell whether that's two single-valued RDNs in a DN,
or one multi-valued RDN with two attribute/value pairs.
Yup, got it. I don't see a way in the OpenSSL library functions I'm
using (X509_NAME_ENTRY_get_object,
Yup, got it. I don't see a way in the OpenSSL library functions I'm
using (X509_NAME_ENTRY_get_object, X509_NAME_ENTRY_get_data) to
distinguish between different RDNs, but I'll take a look at the source
for X509_NAME_print_ex, which does seem to be able to do this.
There's a field on the
Well, that's the same bug that John Nagle complains about.
Yes, I agree.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
OK, I can make it a tuple (list of RDNs) of tuples (one for each RDN)
of tuples (one for each attribute in the RDN).
Which gets us to this:
{'issuer': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
All of this makes me think that some folks may want to do more
processing on certificates with more advanced tools, and for that they
will need access to the full bits of the certificate. I'll add the
ability to retrieve that as well.
I'm wondering if I should try to pull some extension
I'm wondering if I should try to pull some extension attributes out of
the cert, and add them to the dict, as well. Like subjectAltName, for
instance. Or should we just wait till someone wants it and files a
bug report?
If you have the time and inclination to do that, feel free to.
I'm wondering if I should try to pull some extension attributes out of
the cert, and add them to the dict, as well. Like subjectAltName, for
instance. Or should we just wait till someone wants it and files a
bug report?
If you have the time and inclination to do that, feel free
I'm looking at building a frozenset instance as a return value from
a C function, and the C API seems ridiculously clumsy. Maybe I'm
misunderstanding it. Apparently, I need to create a list object, then
pass that to PyFrozenSet_New(), then decref the list object.
Is that correct?
What I'd like
to tuple at this level, and I
suggest that a similar set of C construction functions would be a good
thing.
Bill
I guess nobody has tried to create frozenset instances from C code
before. Almost everyone uses set anyway. What are you trying to do?
On 9/4/07, Bill Janssen [EMAIL PROTECTED] wrote
Raymond, thanks for the note.
You can create a frozenset from any iterable using PyFrozenSet_New().
If you don't have an iterable and want to build-up the frozenset one element
at a time, the approach is to create a regular set (or some other mutable
container), add to it, then convert it
But your point is still well taken. How about this one, though:
PyDict_NEW(int) = PySetObject *
PyDict_ADD(s, value)
ADD would just stick value in the next empty slot (and steal its
reference).
Sorry, I meant to say
PyFrozenSet_NEW(int) = PySetObject *
X.509 DNs are sets of X.500 attributes, and X.500
attributes may be either single-valued or multiple-valued.
Conceptually perhaps (although I doubt that).
I got that from David Chadwick's book at http://sec.cs.kent.ac.uk/x500book/.
``An attribute comprises an attribute type and one or
Dicts, sets and frozenset are implemented as hash tables, not as arrays,
I see, thanks.
The location of the next empty slot depends on a the key
associated with the value being added (btw, where is the key handled
in your proposed API?).
What key? It's a set, not a mapping. The value is
In any case, it certainly sounds to me as if there can be multiple
instances of AttributeTypeAndValue with the same type field in a
single Name. So I'll represent them as tuples, which will preserve
the order in which they occur in the certificate, and make the value
immutable. Applications
I'm wondering if it would be OK to remove the FakeSocket class in
httplib? Actually, it's currently a function that returns one of its
arguments. It's not documented as part of the module, and not used
elsewhere in the rest of the library.
Bill
___
Yep, that includes unit tests. OK, I'll add the deprecation warning.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I think the spec would be the socket API. For sockets, that is POSIX.
According to
http://www.opengroup.org/pubs/online/7908799/xns/getsockname.html
the result is unspecified if the socket has not been bound to a local
name.
However, Windows does not implement POSIX here; instead, it
Transmitting file data .subversion/libsvn_client/commit.c:832:
(apr_err=165001)
svn: Commit failed (details follow):
/build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_repos/hooks.c:135:
(apr_err=165001)
svn: 'pre-commit' hook failed with error output:
file
All right, this is committed. Let's see if the Windows buildbots like
it.
Bill
So, the patch is attached to issue 1052. I sent it out to python-dev,
but it got blocked (too big).
http://bugs.python.org/file8352/ssl-patch-5
This contains a number of things:
1) Improve the
Yes, the Windows buildbots seem happy now with ssl. I'm going to
expand the test suite.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Sun, 26 Aug 2007, Bill Janssen wrote:
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
Looking at the buildbots today, Windows is still unhappy. It seems to
have gotten further, though.
The problematic test is this one:
File C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_ssl.py,
line 77, in testSSLconnect
s.connect((pop.gmail.com, 995))
File
The problematic test is this one:
File C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_ssl.py,
line 77, in testSSLconnect
s.connect((pop.gmail.com, 995))
File C:\buildbot_py25\trunk.mcintyre-windows\build\lib\ssl.py, line 170,
in connect
if self._sslobj or
Well, that's just what you get with two independent implementations of
a spec. We don't try to hide the differences between the sockets stack
in Unix and Windows -- you'll just have to work around it.
No problem. But I think it's still a bug -- the spec (where is it?)
should say what we want.
So, the patch is attached to issue 1052. I sent it out to python-dev,
but it got blocked (too big).
http://bugs.python.org/file8352/ssl-patch-5
This contains a number of things:
1) Improve the documentation of the SSL module, with a fuller
explanation of certificate usage, another
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.
Well, if you have OpenSSL in the first place, you'll have the binary,
won't you? But I agree it's unlikely to be on your path. As for Ubuntu
Regardless, building a fixed test certificate and checking it in sounds like
the better option. Then the openssl command in the test code can be turned
into a comment describing how the test data was pregenerated.
Here's a patch that does that.
Bill
Index: Lib/test/keycert.pem
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
Anything else I can check in for you?
Ho, ho!
No, I'm done for now. I think everything is working; let's see what
the buildbots say. I've got to do some job work now, and I promised
Barry I'd help with the email work, but I'll get back to this with a
port to the Py3K branch. I'd also like to
I think the next steps to take are as follows, in order:
1) Generate a patch to the trunk to remove all use of socket.ssl in
library modules (and elsewhere except for
test/test_socket_ssl.py), and switch them to use the ssl module.
This would affect httplib, imaplib, poplib, smtplib,
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
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
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
301 - 400 of 502 matches
Mail list logo
