> 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 u
> 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,
> 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(
> > "open
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 "C:\buildbo
> 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._s
> 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 w
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 reference,
> 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; ins
> 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 /python/trunk/
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 docu
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:
http://mail.python.org/mailman/options/python
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
___
Pyt
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:
http://mail.python.org/mailman/options/python-dev/archive%40mail
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 lik
icularly "issubset" and "issuperset".
I think frozenset is quite analogous 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. Almos
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 conver
> 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 *
PyFro
> > 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 o
> 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 val
> 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. Applic
> > 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
> > immutabl
>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
Certificat
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
Pyth
> 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, X
> 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:
http://mail.python.org/mailman/options/python-dev/archive%
> 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 attribute
> > 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 fr
> > > 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 t
> 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
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 Addr
> 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 0x9194
> 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 / Py_
> 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: /local/python/t
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
__
things), or (2) remove 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
> 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
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
PyThrea
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
http://mail.python.org/mailman/listinfo/python-d
> 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 test_soc
> > 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 testi
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
_
> We're already linking against the OpenSSL EVP libraries for hashlib
> (and against the OpenSSL SSL libraries for the SSL support). It
> wouldn't be hard to expose the EVP functions a bit more, essentially
> as hash functions that return long (and reversible) hashes:
>
>encryptor = opensslev
"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 /usr/include/servers/bootstra
> > 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
> > "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 S
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 package
> 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 proto
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 defaul
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
http://mail
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,
> expect
> > 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 m
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 t
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 te
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
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 http://www.par
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 alr
> > 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
> > (usuall
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:
http://
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 f
> 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:
http://mai
> 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 HT
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
Python-Dev@python.or
> 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
> 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 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
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 th
> 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
http://mail.python.org/mailm
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 elim
> 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:
http://mail.python.org/ma
> > 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 f
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 fr
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 package
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
http://mail.python.org/mailman/listinfo/pyth
> 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 langua
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=ssl&version=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=ssl&version=1.5&;
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
For some reason, it was set to be 'hidden'.
Try
http://pypi.python.org/pypi/ssl/1.5
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
> BTW, there's still an asyncore bug with Python 2.4. I can't recall if
> that's a known issue. It was in 1.3 (I didn't ever get to 1.4).
Hmmm, I just build Python 2.4.4 and tried it (on a Mac), and it seems
to work fine. Must be a Windows issue, somehow. Any ideas?
Bill
___
I've now got a large complex long-lived threaded server asyncore-based
(Medusa) multi-client server program running on OS X with Python 2.3.5
and the "older-Python" SSL module. I had to make a number of changes
to the code; primarily fixing the way that certain "socket" methods
are called on the S
201 - 300 of 537 matches
Mail list logo
