From reitz at INWORKS.DE Tue Jun 1 10:23:03 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Tue, 1 Jun 2004 10:23:03 +0200 Subject: [PYTHON-CRYPTO] SSL.Connection and select Message-ID: <20040601102303.1ac29086.reitz@inworks.de> Hi, I just read an old discussion about SSL-Sockets and select. Therefore a question: Does the standard select function work on SSL-Sockets or not? I need a blocking SSL Connection. Because my application is a multithreaded server, I use: self._connection=SSL.Connection(...) self._connection.setblocking(0) ... and then: def _read(self,count): assert count>0 try: while 1: s=self._connection.read(count) if s==None: time.sleep(0.001) else: assert s #s must not be ""! return s #less than count bytes is ok except SSL.SSLError,err: if err.args[0]=="unexpected eof": return "" #EOF else : raise Now I want to get rid of the time.sleep(0.001). My Idea is to use select, but I am confused if it is a correct way to use select on a SSL-Socket. Thank you very much in advance, Greetings, Andre' -- __________________________________________________________________________ Als Technologieunternehmen konzipieren und entwickeln wir ma?geschneiderte Feedback- und Monitoring-Systeme - wie beispielsweise L?sungen f?r Beschwerde- und Ideenmanagement. Mit dem Inquery? Survey Server bieten wir eine der leistungsf?higsten Standardl?sungen f?r Online-Umfragen mit dem Schwerpunkt auf der Messung von Kundenzufriedenheit an. __________________________________________________________________________ Inworks GmbH Andre Reitz, Leiter Entwicklung H?rvelsinger Weg 39, 89081 Ulm, Germany Tel +49 (0) 731 / 93807-21 Fax +49(0)731/93807-18 Internet: http://www.inworks.de From ludo at ASIATICA.ORG Wed Jun 2 02:23:35 2004 From: ludo at ASIATICA.ORG (Ludovico Magnocavallo) Date: Wed, 2 Jun 2004 02:23:35 +0200 Subject: [PYTHON-CRYPTO] signed SMIME verification Message-ID: <40BD1E07.9000209@asiatica.org> I've been working a bit on SMIME with M2Crypto recently, and I noticed there's no recipe in the M2Crypto docs on how to verify a signed mail without knowing the signer's certificate. Openssl's "smime verify" command is able to do that, and the same thing can be accomplished with M2Crypto. I've wrapped up my findings in a simple class which can be found at http://www.asiatica.org/~ludo/archive/2004/05/Python_smime_verify.html Please let me know if there are errors/inconsistencies or better ways of doing this. Ludo From terry at BIZARSOFTWARE.COM.AU Wed Jun 2 10:36:18 2004 From: terry at BIZARSOFTWARE.COM.AU (Terry Kerr) Date: Wed, 2 Jun 2004 18:36:18 +1000 Subject: [PYTHON-CRYPTO] M2Crypto upgrade problems. Message-ID: <40BD9182.8070201@bizarsoftware.com.au> Hi, I am new to this list, and pretty much an amature with M2Crypto. We have a product which used M2Crypto 0.08 with python 2.1.3 for SMIME encryption of e-mails. I am investigating the task of upgrading our product to use python2.3.3 and the latest M2Crypto (0.13). The product is built on Zope 2.7 with ZServerSSL, and the ZServerSSL works fine, however, the SMIME encryption part of our product doesn't...it Seg Faults! Further investigation shows that demo/smime/test.py also doesn't work, it also seg faults in the same way. I am running on debian linux with: - source install of python 2.3.3 - source install of openssl-0.9.7d - source install of m2crypto-0.13 - debian package install of 1.3.21-5 The seg fault occurs on the actual s.encrypt(buf) call in test.py in the encrypt/decrypt test which I have included for your convenience: def ed(): print 'test encrypt/decrypt...', buf = makebuf() s = SMIME.SMIME() # Load target cert to encrypt to. x509 = X509.load_cert('client.pem') sk = X509.X509_Stack() sk.push(x509) s.set_x509_stack(sk) # Add a cipher. s.set_cipher(SMIME.Cipher('bf_cbc')) # Encrypt. p7 = s.encrypt(buf) # Load target's private key. s.load_key('client.pem') # Decrypt. data = s.decrypt(p7) if data: print 'ok' else: print 'not ok' The unit tests for M2Crypto run without errors. I am lost for what to try to fix this. Is something wrong with my configuration of openssl or python? I am hoping somebody can point me in the right direction because this is an absolute show stopper as far as our planned upgrade goes ;-( terry From wiget at PLD-LINUX.ORG Wed Jun 2 11:33:49 2004 From: wiget at PLD-LINUX.ORG (Artur Frysiak) Date: Wed, 2 Jun 2004 11:33:49 +0200 Subject: [PYTHON-CRYPTO] M2Crypto upgrade problems. In-Reply-To: <40BD9182.8070201@bizarsoftware.com.au> References: <40BD9182.8070201@bizarsoftware.com.au> Message-ID: <20040602093349.GA15485@ikar.t17.ds.pwr.wroc.pl> On Wed, Jun 02, 2004 at 06:36:18PM +1000, Terry Kerr wrote: > Hi, > > I am new to this list, and pretty much an amature with M2Crypto. We > have a product which used M2Crypto 0.08 with python 2.1.3 for SMIME > encryption of e-mails. I am investigating the task of upgrading our > product to use python2.3.3 and the latest M2Crypto (0.13). > The product is built on Zope 2.7 with ZServerSSL, and the ZServerSSL > works fine, however, the SMIME encryption part of our product > doesn't...it Seg Faults! > > Further investigation shows that demo/smime/test.py also doesn't work, > it also seg faults in the same way. > > I am running on debian linux with: > - source install of python 2.3.3 > - source install of openssl-0.9.7d > - source install of m2crypto-0.13 > - debian package install of 1.3.21-5 > > The seg fault occurs on the actual s.encrypt(buf) call in test.py in the > encrypt/decrypt test which I have included for your convenience: This is openssl 0.9.7d problem. Aplly http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/openssl-smime.patch?rev=1.1 (extracted from http://cvs.openssl.org/chngview?cn=12080) and recompile openssl. Regards -- Artur Frysiak http://www.pld-linux.org/ From petvajda at YAHOO.COM Fri Jun 4 10:54:24 2004 From: petvajda at YAHOO.COM (Peter Vajda) Date: Fri, 4 Jun 2004 01:54:24 -0700 Subject: [PYTHON-CRYPTO] HTTPSConnection question Message-ID: <20040604085424.47975.qmail@web20904.mail.yahoo.com> Hi, I am writing a performance test application for an HTTPS server with M2Crypto. All clients will load same time the server and should use the same certificate and primary key. I would like that the files (cert, key) just read once during initialization. I made the following class but after the handshake my application is stuck no response. Could somebody help what should be the problem? Thanks Peter Vajda class MyHTTPSConnection(HTTPSConnection): try: Rand.load_file('./httpsd/randpool.dat', -1) ctx=SSL.Context('sslv23') ctx.load_cert(CERT_FILE, KEY_FILE) ctx.set_verify(SSL.verify_none, 0) ctx.set_info_callback() except: raise def __init__(self, host): try: server, port=host.split(':') self.conn=HTTPSConnection(server, string.atoi(port), ssl_context=MyHTTPSConnection.ctx) self.set_debuglevel(1) except: raise def request(self, method, url, body=None, headers={}): return self.conn.request(method, url, body, headers) def getresponse(self): return self.conn.getresponse() __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From carnesm at LUCENT.COM Tue Jun 22 01:54:19 2004 From: carnesm at LUCENT.COM (CARNES, MARK E (MARK)) Date: Mon, 21 Jun 2004 18:54:19 -0500 Subject: [PYTHON-CRYPTO] m2crypto - close_wait when running echod_async Message-ID: <17D8724A2A8D9542B2B8AE546B9E5BBC0217694F@AZ4315EXCH001U> I've been looking at a server that is using the SSL.ssl_dispatcher and asyncore.dispatcher, and noticed file descriptors that aren't being closed. I went back and ran the echod_async example from the demo directory and interestingly enough got the same result. It looks like the socket is never being closed on the server side. If I manually go do a self.socket.socket.close() I can get it to go away, but it looks like it normally wouldn't call that method unless it goes through the __del__ method in Connection, and the reference count was never going to 0. The end result is that the "Connection" class self references its own methods "self._write_bio", and "self._write_nbio", which causes a circular reference and if you don't have garbage collection enabled, this object never gets collected. I tested a variation of "Connection" where I just created a "self.mode" and corresponding "self.send", "self.write", "self.recv", and "self.read" methods instead of using the method references. Is there a better way to approach this problem? Here's the code I changed ------------------------------------------------------------------------------------------------------------------------------------------------------------- <> class Connection: """An SSL connection.""" def __init__(self, ctx, sock=None): self.ctx = ctx self.ssl = m2.ssl_new(self.ctx.ctx) if sock is not None: self.socket = sock else: self.socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self._fileno = self.socket.fileno() self.mode = 0 # -- ADDED <> def setblocking(self, mode): """Set this connection's underlying socket to _mode_.""" self.socket.setblocking(mode) self.mode = mode # -- ADDED # if mode: -- REMOVED # self.send = self.write = self._write_bio -- REMOVED # self.recv = self.read = self._read_bio -- REMOVED # else: -- REMOVED # self.send = self.write = self._write_nbio -- REMOVED # self.recv = self.read = self._read_nbio -- REMOVED # NEW METHODS FOLLOW def send(self, data): if self.mode: return self._write_bio(data) else: return self._write_nbio(data) def write(self, data): if self.mode: return self._write_bio(data) else: return self._write_nbio(data) def recv(self, size=1024): if self.mode: return self._read_bio(size) else: return self._read_nbio(size) def read(self, size=1024): if self.mode: return self._read_bio(size) else: return self._read_nbio(size) # END NEW METHODS <> From reitz at INWORKS.DE Tue Jun 22 11:47:28 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Tue, 22 Jun 2004 11:47:28 +0200 Subject: [PYTHON-CRYPTO] m2crypto - close_wait when running echod_async In-Reply-To: <17D8724A2A8D9542B2B8AE546B9E5BBC0217694F@AZ4315EXCH001U> References: <17D8724A2A8D9542B2B8AE546B9E5BBC0217694F@AZ4315EXCH001U> Message-ID: <20040622114728.321b7922.reitz@inworks.de> I did the same for me. I think that this is the only solution. By the way: the patch on m2crypto homepage doesn't work at all (at least under Python 2.2) http://sandbox.rulemaker.net/ngps/Dist/0.13p1.patch <<--doesn't work. Greetings, Andre' On Mon, 21 Jun 2004 18:54:19 -0500 "CARNES, MARK E (MARK)" wrote: > I've been looking at a server that is using the SSL.ssl_dispatcher and asyncore.dispatcher, and noticed > file descriptors that aren't being closed. I went back and ran the echod_async example from the demo > directory and interestingly enough got the same result. > > It looks like the socket is never being closed on the server side. If I manually go do a self.socket.socket.close() > I can get it to go away, but it looks like it normally wouldn't call that method unless it goes through the __del__ > method in Connection, and the reference count was never going to 0. > > The end result is that the "Connection" class self references its own methods "self._write_bio", and "self._write_nbio", > which causes a circular reference and if you don't have garbage collection enabled, this object never gets collected. > > I tested a variation of "Connection" where I just created a "self.mode" and corresponding "self.send", "self.write", "self.recv", > and "self.read" methods instead of using the method references. > > Is there a better way to approach this problem? > > Here's the code I changed > > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > <> > > class Connection: > > """An SSL connection.""" > > def __init__(self, ctx, sock=None): > self.ctx = ctx > self.ssl = m2.ssl_new(self.ctx.ctx) > if sock is not None: > self.socket = sock > else: > self.socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) > self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) > self._fileno = self.socket.fileno() > self.mode = 0 # -- ADDED > > <> > > def setblocking(self, mode): > """Set this connection's underlying socket to _mode_.""" > self.socket.setblocking(mode) > self.mode = mode # -- ADDED > # if mode: -- REMOVED > # self.send = self.write = self._write_bio -- REMOVED > # self.recv = self.read = self._read_bio -- REMOVED > # else: -- REMOVED > # self.send = self.write = self._write_nbio -- REMOVED > # self.recv = self.read = self._read_nbio -- REMOVED > > # NEW METHODS FOLLOW > > def send(self, data): > if self.mode: > return self._write_bio(data) > else: > return self._write_nbio(data) > > def write(self, data): > if self.mode: > return self._write_bio(data) > else: > return self._write_nbio(data) > > def recv(self, size=1024): > if self.mode: > return self._read_bio(size) > else: > return self._read_nbio(size) > > def read(self, size=1024): > if self.mode: > return self._read_bio(size) > else: > return self._read_nbio(size) > > # END NEW METHODS > > <> -- __________________________________________________________________________ Als Technologieunternehmen konzipieren und entwickeln wir ma?geschneiderte Feedback- und Monitoring-Systeme - wie beispielsweise L?sungen f?r Beschwerde- und Ideenmanagement. Mit dem Inquery? Survey Server bieten wir eine der leistungsf?higsten Standardl?sungen f?r Online-Umfragen mit dem Schwerpunkt auf der Messung von Kundenzufriedenheit an. __________________________________________________________________________ Inworks GmbH Andre Reitz, Leiter Entwicklung H?rvelsinger Weg 39, 89081 Ulm, Germany Tel +49 (0) 731 / 93807-21 Fax +49(0)731/93807-18 Internet: http://www.inworks.de From ngps at POST1.COM Tue Jun 22 17:13:37 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Tue, 22 Jun 2004 23:13:37 +0800 Subject: [PYTHON-CRYPTO] m2crypto - close_wait when running echod_async In-Reply-To: <20040622114728.321b7922.reitz@inworks.de> References: <17D8724A2A8D9542B2B8AE546B9E5BBC0217694F@AZ4315EXCH001U> <20040622114728.321b7922.reitz@inworks.de> Message-ID: <20040622151337.GC369@vista.netmemetic.com> On Tue, Jun 22, 2004 at 11:47:28AM +0200, Andre Reitz wrote: > By the way: > the patch on m2crypto homepage > doesn't work at all (at least under Python 2.2) My bad. Day job is killing me, but I should get a very short break coming up in the next 2 or 3 days so I can clean some of this up. (Well, you know a programmer always estimates in elastic time, so... ;-) Anyhow, given the increased pace of Python development, I find it hard to keep up. I have Python 2.1, because I'm running Zope 2.6 in production in a few places. Any other Python stuff I do is with 2.3. I don't think I've fired up the 2.2 interpreter in a long time. So "cleaning up" may simply mean declaring that Pythons prior to 2.3 can't be catered to. Sorry. Cheers. -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Version Control http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers From reitz at INWORKS.DE Wed Jun 23 10:07:10 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Wed, 23 Jun 2004 10:07:10 +0200 Subject: [PYTHON-CRYPTO] m2crypto - close_wait when running echod_async In-Reply-To: <20040622151337.GC369@vista.netmemetic.com> References: <17D8724A2A8D9542B2B8AE546B9E5BBC0217694F@AZ4315EXCH001U> <20040622114728.321b7922.reitz@inworks.de> <20040622151337.GC369@vista.netmemetic.com> Message-ID: <20040623100710.6450db6c.reitz@inworks.de> On Tue, 22 Jun 2004 23:13:37 +0800 Ng Pheng Siong wrote: > On Tue, Jun 22, 2004 at 11:47:28AM +0200, Andre Reitz wrote: > > By the way: > > the patch on m2crypto homepage > > doesn't work at all (at least under Python 2.2) > > My bad. > > Day job is killing me, but I should get a very short break coming up in the > next 2 or 3 days so I can clean some of this up. > > (Well, you know a programmer always estimates in elastic time, so... ;-) > > Anyhow, given the increased pace of Python development, I find it hard to > keep up. I have Python 2.1, because I'm running Zope 2.6 in production in a > few places. Any other Python stuff I do is with 2.3. I don't think I've > fired up the 2.2 interpreter in a long time. > > So "cleaning up" may simply mean declaring that Pythons prior to 2.3 can't > be catered to. Sorry. > > Cheers. > > -- > Ng Pheng Siong > No real problem. Anyway, m2crypto is very useful for us. :) By the way, a simple question: Is it possible to use select() on a M2Crypto.SSL.Connection? Greetings, Andre' -- __________________________________________________________________________ Als Technologieunternehmen konzipieren und entwickeln wir ma?geschneiderte Feedback- und Monitoring-Systeme - wie beispielsweise L?sungen f?r Beschwerde- und Ideenmanagement. Mit dem Inquery? Survey Server bieten wir eine der leistungsf?higsten Standardl?sungen f?r Online-Umfragen mit dem Schwerpunkt auf der Messung von Kundenzufriedenheit an. __________________________________________________________________________ Inworks GmbH Andre Reitz, Leiter Entwicklung H?rvelsinger Weg 39, 89081 Ulm, Germany Tel +49 (0) 731 / 93807-21 Fax +49(0)731/93807-18 Internet: http://www.inworks.de From ngps at POST1.COM Wed Jun 23 11:43:13 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Wed, 23 Jun 2004 17:43:13 +0800 Subject: [PYTHON-CRYPTO] m2crypto - close_wait when running echod_async In-Reply-To: <20040623100710.6450db6c.reitz@inworks.de> References: <17D8724A2A8D9542B2B8AE546B9E5BBC0217694F@AZ4315EXCH001U> <20040622114728.321b7922.reitz@inworks.de> <20040622151337.GC369@vista.netmemetic.com> <20040623100710.6450db6c.reitz@inworks.de> Message-ID: <20040623094313.GA271@vista.netmemetic.com> On Wed, Jun 23, 2004 at 10:07:10AM +0200, Andre Reitz wrote: > Is it possible to use select() on a M2Crypto.SSL.Connection? ZServerSSL extends the Medusa-based ZServer, Medusa uses select, ZServerSSL works, so it is possible! ;-) But currently it is a bit roundabout: asyncore's dispatcher class, upon which ZServer is based, has this magic method: # cheap inheritance, used to pass all other attribute # references to the underlying socket object. def __getattr__ (self, attr): return getattr (self.socket, attr) SSL.Connection conveniently stores its underlying socket object as the instance variable "socket", so the above magic method allows Medusa to work with ZServerSSL's SSL.Connection object without any explicit code to do so. You may wish to add either the above magic method to class SSL.Connection, or an explicit "select" method. (I'd do it myself when I find the time, probably the former.) Cheers. -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Version Control http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers From reitz at INWORKS.DE Wed Jun 23 16:03:28 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Wed, 23 Jun 2004 16:03:28 +0200 Subject: [PYTHON-CRYPTO] m2crypto - close_wait when running echod_async In-Reply-To: <20040623094313.GA271@vista.netmemetic.com> References: <17D8724A2A8D9542B2B8AE546B9E5BBC0217694F@AZ4315EXCH001U> <20040622114728.321b7922.reitz@inworks.de> <20040622151337.GC369@vista.netmemetic.com> <20040623100710.6450db6c.reitz@inworks.de> <20040623094313.GA271@vista.netmemetic.com> Message-ID: <20040623160328.48c47cfd.reitz@inworks.de> On Wed, 23 Jun 2004 17:43:13 +0800 Ng Pheng Siong wrote: > On Wed, Jun 23, 2004 at 10:07:10AM +0200, Andre Reitz wrote: > > Is it possible to use select() on a M2Crypto.SSL.Connection? > > ZServerSSL extends the Medusa-based ZServer, Medusa uses select, ZServerSSL > works, so it is possible! ;-) > > But currently it is a bit roundabout: asyncore's dispatcher class, upon > which ZServer is based, has this magic method: > > # cheap inheritance, used to pass all other attribute > # references to the underlying socket object. > def __getattr__ (self, attr): > return getattr (self.socket, attr) > > SSL.Connection conveniently stores its underlying socket object as the > instance variable "socket", so the above magic method allows Medusa to work > with ZServerSSL's SSL.Connection object without any explicit code to do so. > > You may wish to add either the above magic method to class SSL.Connection, > or an explicit "select" method. (I'd do it myself when I find the time, > probably the former.) > > Cheers. Thanks for your quick response. What I meant is: is it legal to use the standard select method on the underlying socket of a m2crypto SSL.Connection Object, or are there problems bacause of the ssl-protocol lying on the socket? Greetings, Andre' > > -- > Ng Pheng Siong > > http://firewall.rulemaker.net -+- Firewall Version Control > http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers -- __________________________________________________________________________ Als Technologieunternehmen konzipieren und entwickeln wir ma?geschneiderte Feedback- und Monitoring-Systeme - wie beispielsweise L?sungen f?r Beschwerde- und Ideenmanagement. Mit dem Inquery? Survey Server bieten wir eine der leistungsf?higsten Standardl?sungen f?r Online-Umfragen mit dem Schwerpunkt auf der Messung von Kundenzufriedenheit an. __________________________________________________________________________ Inworks GmbH Andre Reitz, Leiter Entwicklung H?rvelsinger Weg 39, 89081 Ulm, Germany Tel +49 (0) 731 / 93807-21 Fax +49(0)731/93807-18 Internet: http://www.inworks.de From terry at BIZARSOFTWARE.COM.AU Fri Jun 25 07:38:53 2004 From: terry at BIZARSOFTWARE.COM.AU (Terry Kerr) Date: Fri, 25 Jun 2004 07:38:53 +0200 Subject: [PYTHON-CRYPTO] M2Crypto build problems. Message-ID: Hi, The m2crypto I built doesnt work. I get the error: >>> import M2Crypto Traceback (most recent call last): File "", line 1, in ? File "/home/builder/lib/python2.3/site-packages/M2Crypto/__init__.py", line 7, in ? import __m2crypto ImportError: /home/builder/lib/python2.3/site- packages/M2Crypto/__m2crypto.so: Undefined symbol "EVP_aes_192_cfb" I built and are running on a freebsd 4.3 system. I built python2.3.3 from source, swig 1.3.21 from source, openssl-0.9.7d from source and m2crypto0.13 from source. I had no problems building, but X-Mozilla-Status: 8000 X-Mozilla-Status2: 00000000 the module just won't load. The openssl tests also run without any problems. I didn't see anything related to this in the mailing list or when I seached google? I used the exact same source downloads of openssl, python, swig and m2crypto to build a working version of m2crypto on a debian linux system, so I assume the fault has something to do with my freebsd system, but I can't image what. I had m2crypto 0.06 running in python 2.1.1 on this machine previously, and it worked OK. I am a bit of a beginner...can somebody point me in the right direction? Thanks. Terry From ngps at POST1.COM Fri Jun 25 19:27:23 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Sat, 26 Jun 2004 01:27:23 +0800 Subject: [PYTHON-CRYPTO] M2Crypto build problems. In-Reply-To: References: Message-ID: <20040625172723.GD3043@vista.netmemetic.com> On Fri, Jun 25, 2004 at 07:38:53AM +0200, Terry Kerr wrote: > >>> import M2Crypto > Traceback (most recent call last): > File "", line 1, in ? > File "/home/builder/lib/python2.3/site-packages/M2Crypto/__init__.py", > line 7, in ? > import __m2crypto > ImportError: /home/builder/lib/python2.3/site- > packages/M2Crypto/__m2crypto.so: Undefined symbol "EVP_aes_192_cfb" What says "objdump -x __m2crypto.so"? I get: Dynamic Section: NEEDED libssl.so.3 NEEDED libcrypto.so.3 I've recently upgraded my FreeBSD world to 4.10-RELEASE. These .so's are the system-built ones. $ which openssl /usr/bin/openssl $ /usr/bin/openssl version OpenSSL 0.9.7d 17 Mar 2004 $ objdump -T __m2crypto.so | egrep aes 00000000 DF *UND* 00000019 EVP_aes_192_cfb 00000000 DF *UND* 00000019 EVP_aes_128_cbc 00000000 DF *UND* 00000019 EVP_aes_192_ecb 00000000 DF *UND* 00000019 EVP_aes_128_cfb 00000000 DF *UND* 00000019 EVP_aes_192_cbc 00000000 DF *UND* 00000019 EVP_aes_256_cbc 00000000 DF *UND* 00000019 EVP_aes_128_ecb 00000000 DF *UND* 00000019 EVP_aes_192_ofb 00000000 DF *UND* 00000019 EVP_aes_128_ofb 00000000 DF *UND* 00000019 EVP_aes_256_ofb 00000000 DF *UND* 00000019 EVP_aes_256_cfb 00000000 DF *UND* 00000019 EVP_aes_256_ecb $ python >>> from M2Crypto import EVP >>> c = EVP.Cipher('aes_192_cfb', 'key', '', 1, 1, 'sha1', 'saltsalt', 1) >>> c > I used the exact same source downloads of openssl, python, swig and > m2crypto to build a working version of m2crypto on a debian linux system, > so I assume the fault has something to do with my freebsd system, but I > can't image what. Perhaps you have more than 1 installation of OpenSSL on your system, and are somehow linking with the old one? Python and SWIG builds aren't relevant in this case. (BTW, FreeBSD 4.3 is _really_ ancient.) HTH. Cheers. -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Version Control http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL/Zope, Blog From ngps at POST1.COM Fri Jun 25 19:43:11 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Sat, 26 Jun 2004 01:43:11 +0800 Subject: [PYTHON-CRYPTO] m2crypto - close_wait when running echod_async In-Reply-To: <20040623160328.48c47cfd.reitz@inworks.de> References: <17D8724A2A8D9542B2B8AE546B9E5BBC0217694F@AZ4315EXCH001U> <20040622114728.321b7922.reitz@inworks.de> <20040622151337.GC369@vista.netmemetic.com> <20040623100710.6450db6c.reitz@inworks.de> <20040623094313.GA271@vista.netmemetic.com> <20040623160328.48c47cfd.reitz@inworks.de> Message-ID: <20040625174311.GF3043@vista.netmemetic.com> On Wed, Jun 23, 2004 at 04:03:28PM +0200, Andre Reitz wrote: > is it legal to use the standard select method on the underlying socket of a > m2crypto SSL.Connection Object, > or are there problems bacause of the ssl-protocol lying on the socket? Ah, I misread your question earlier. Yes it is okay to use select to test the underlying socket. However, you must use SSL's read/write functions (i.e., SSL.Connection's read/write methods) when select indicates the socket is readable/writeable respectively. This is because the SSL protocol adds crypto overhead to your data; when select reports that the socket is writeable, say, SSL might need to _read_ and write stuff over the wire that is SSL-specific and has nothing to do with your data, and the SSL functions handle this properly. Also take a look at contrib/dave.README, from Dave Brueck in 2002: The ssl_connect, ssl_read_nbio, etc. calls don't differentiate between SSL_ERROR_WANT_WRITE and SSL_ERROR_WANT_READ when a non-blocking call couldn't finish. But without this information, I don't know whether the socket needs to do more reading or more writing before a subsequent attempt will work without blocking. The demo applications (e.g. echod-async.py) don't seem to care about this but they get around it by simply trying the operation over and over again, which I can't do for performance reasons. I use ZServerSSL over the net and haven't encountered any performance problems. I was asking Dave if he has more info on the improvement in performance, but our email conversation kinda petered out. Cheers. -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Version Control http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL/Zope, Blog