From heikki at OSAFOUNDATION.ORG Thu Apr 1 04:31:17 2004 From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen) Date: Wed, 31 Mar 2004 18:31:17 -0800 Subject: [PYTHON-CRYPTO] [Announce] PyEGADS Message-ID: <406B7EF5.9070302@osafoundation.org> PyEGADS is a Python wrapper for EGADS, which is a cryptographically strong pseudo-random number generator and entropy daemon. PyEGADS is cross platform, and open source. PyEGADS is a Python extension developed with SWIG toolkit and Python programming language. PyEGADS provides cryptographically strong pseudo-random numbers and strings, and raw entropy suitable for seeding OpenSSL and similar libraries (a good OpenSSL wrapper for Python is M2Crypto). PyEGADS seems to work fine on Windows, but experiences strange problems on Linux - any help would be appreciated. Some issues I'm having on Linux: setup does not do everything correctly and requires manual steps afterwards, crash or other bad state after calling destroy() (or sometimes after other functions as well). For more details see http://wiki.osafoundation.org/twiki/bin/view/Chandler/PyEgads -- Heikki Toivonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From heikki at OSAFOUNDATION.ORG Thu Apr 1 04:53:13 2004 From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen) Date: Wed, 31 Mar 2004 18:53:13 -0800 Subject: [PYTHON-CRYPTO] M2Crypto improvements Message-ID: <406B8419.90003@osafoundation.org> I was working on some M2Crypto improvements and was about to submit my patch when 0.13 came out and it happened to contain *some* of the same changes I had made. Basically, I had added support for creating certificates (with extensions), and added stuff that was recommended by the OpenSSL book. I also generated Epydoc documentation. I added Epydoc comments to all the functions I added, so there is more than what was submitted for 0.13. You can view it online at: http://lxr.osafoundation.org/source/osaf/chandler/m2crypto/doc/api/index.html You can get a diff of my changes like this (against 0.12 release): * Set your CVSROOT environment variable to: :pserver:anonymous at cvs.osafoundation.org:/usr/local/cvsrep * cvs login (the password is "anonymous") * cvs checkout osaf/chandler/m2crypto * cvs diff -u9N -rM2CRYPTO_0_12 -rHEAD osaf/chandler/m2crypto I will be looking at making a patch against 0.13.1, but if anyone wants to help, you are certainly welcome. -- Heikki Toivonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From heikki at OSAFOUNDATION.ORG Thu Apr 1 08:14:51 2004 From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen) Date: Wed, 31 Mar 2004 22:14:51 -0800 Subject: [PYTHON-CRYPTO] M2Crypto improvements In-Reply-To: <406B8419.90003@osafoundation.org> References: <406B8419.90003@osafoundation.org> Message-ID: <406BB35B.50909@osafoundation.org> Well, it was easier than I thought, so I was actually able to port my changes to 0.13p1 already. See the attachment for the changes. Some comments: * In my opinion we should get rid of the raw C ptrs in the Python object method parameters if there is a corresponding high level Python object available. For example, we have X509_Name object, therefore we should not pass raw X509_NAME pointers around in the interfaces. Witness X509.set_issuer_name for example. I fixed a couple of these instances, but they should all be fixed. * Look for XXX in my code for TODO parts and things I am unsure about. I think 0.13(p1) has also introduced a bug: the server3/client3 samples used to work in 0.12 with my changes, but now with the attached patch applied against 0.13(p1) the samples no longer work. Namely, I get the following traceback: Traceback (most recent call last): File "server3.py", line 99, in ? ctx = setup_server_ctx() File "server3.py", line 36, in setup_server_ctx ctx.load_cert_chain('server.pem') File "c:\builds\osaf\chandler\release\bin\Lib\site-packages\M2Crypto\SSL\Context.py", line 85, in load_cert_chain m2.ssl_ctx_use_cert_chain(self.ctx, certchainfile) M2Crypto.SSL.SSLError: invalid directory At this point none of my code has been executed (as far as I can see). Can anyone figure out what is going on? -- Heikki Toivonen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: heikki.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From reitz at INWORKS.DE Thu Apr 1 21:04:49 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Thu, 1 Apr 2004 21:04:49 +0200 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040330155521.GB446@vista.netmemetic.com> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> Message-ID: <20040401210449.73ae805c.reitz@inworks.de> Great, thanks to all. Greetings, Andre' On Tue, 30 Mar 2004 23:55:21 +0800 Ng Pheng Siong wrote: > On Tue, Mar 30, 2004 at 07:25:36PM +1200, Michael Dunstan wrote: > > I have seen the same leak when running ZServerSSL. Had to restart the > > server every few days. Until the following change was made for > > setblocking: > > > > - self.send = self.write = self._write_bio > > + self.send = self.write = Connection._write_bio > > _ self.recv = self.read = self._read_bio > > + self.recv = self.read = Connection._read_bio > > else: > > - self.send = self.write = self._write_nbio > > + self.send = self.write = Connection._write_nbio > > - self.recv = self.read = self._read_nbio > > + self.recv = self.read = Connection._read_nbio > > > > Since applying the patch we have not had any memory problems for some > > time. About 8 months now. > > Great! Thanks for the patch Michael. > > Now to roll out 0.13p1! > > > It is quite a simple matter to correct the headers used for the image > > 304's in Zope. There is even an issue in the zope collector about this: > > http://collector.zope.org/Zope/544. Looks like this incorrect handling > > of the headers in zope is intentional to support caching in some > > relic version of apache configured as a proxy server. > > Bad Zope. No biscuit for Zope. > > > Cheers. > > -- > Ng Pheng Siong > > http://firewall.rulemaker.net -+- Firewall Change Management & Version Control > http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL From reitz at INWORKS.DE Thu Apr 1 21:49:07 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Thu, 1 Apr 2004 21:49:07 +0200 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040330155521.GB446@vista.netmemetic.com> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> Message-ID: <20040401214907.4a1f1af3.reitz@inworks.de> Bad news....... This patch doesnt work with python 2.2.3 !!!! something like this happens TypeError: unbound method ...() must be called with ... instance as first argument (got nothing instead) but.... here is my patch, which should work in any case: (but not so efficient) Greetings, Andre' --- M2Crypto/SSL/Connection.py 2004-03-25 07:36:04.000000000 +0100 +++ /home/andre/m2crypto-0.13/M2Crypto/SSL/Connection.py 2004-04-01 21:32:45.000000000 +0200 @@ -120,34 +120,26 @@ connection.""" return m2.ssl_pending(self.ssl) - def _write_bio(self, data): - return m2.ssl_write(self.ssl, data) - - def _write_nbio(self, data): - return m2.ssl_write_nbio(self.ssl, data) - - def _read_bio(self, size=1024): - if size <= 0: - raise ValueError, 'size <= 0' - return m2.ssl_read(self.ssl, size) - - def _read_nbio(self, size=1024): + def _read(self,size=1024): if size <= 0: raise ValueError, 'size <= 0' + if self._blocking: + return m2.ssl_read(self.ssl, size) return m2.ssl_read_nbio(self.ssl, size) - sendall = send = write = _write_bio - recv = read = _read_bio + def _write(self,data): + if self._blocking: + m2.ssl_write(self.ssl, data) + return m2.ssl_write_nbio(self.ssl, data) + + sendall = send = write = _write + recv = read = _read + _blocking=1 def setblocking(self, mode): """Set this connection's underlying socket to _mode_.""" self.socket.setblocking(mode) - if mode: - self.send = self.write = self._write_bio - self.recv = self.read = self._read_bio - else: - self.send = self.write = self._write_nbio - self.recv = self.read = self._read_nbio + self._blocking=mode def fileno(self): return self.socket.fileno() On Tue, 30 Mar 2004 23:55:21 +0800 Ng Pheng Siong wrote: > On Tue, Mar 30, 2004 at 07:25:36PM +1200, Michael Dunstan wrote: > > I have seen the same leak when running ZServerSSL. Had to restart the > > server every few days. Until the following change was made for > > setblocking: > > > > - self.send = self.write = self._write_bio > > + self.send = self.write = Connection._write_bio > > _ self.recv = self.read = self._read_bio > > + self.recv = self.read = Connection._read_bio > > else: > > - self.send = self.write = self._write_nbio > > + self.send = self.write = Connection._write_nbio > > - self.recv = self.read = self._read_nbio > > + self.recv = self.read = Connection._read_nbio > > > > Since applying the patch we have not had any memory problems for some > > time. About 8 months now. > > Great! Thanks for the patch Michael. > > Now to roll out 0.13p1! > > > It is quite a simple matter to correct the headers used for the image > > 304's in Zope. There is even an issue in the zope collector about this: > > http://collector.zope.org/Zope/544. Looks like this incorrect handling > > of the headers in zope is intentional to support caching in some > > relic version of apache configured as a proxy server. > > Bad Zope. No biscuit for Zope. > > > Cheers. > > -- > Ng Pheng Siong > > http://firewall.rulemaker.net -+- Firewall Change Management & Version Control > http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL -------------- next part -------------- A non-text attachment was scrubbed... Name: m2crypto-0.13-andre-nbio.patch Type: application/octet-stream Size: 1608 bytes Desc: not available URL: From reitz at INWORKS.DE Thu Apr 1 23:25:53 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Thu, 1 Apr 2004 23:25:53 +0200 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040401214907.4a1f1af3.reitz@inworks.de> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> Message-ID: <20040401232553.040763eb.reitz@inworks.de> Another question.... since my patch about the memory leak (when called setblocking(x)). i have another problem. We use m2crypto with a multithreaded python server. I am pretty sure, that since the Connection object gets garbage collected (and the __del__ method gets called) the server sometimes hangs completely. I suspect that the EOF/Connectionloss of a client may block the server in m2.bio_free(self.sslbio) or m2.bio_free(self.sockbio) or self.socket.close() which on the other hand blocks all other threas reading and writing to their own connections... IN OTHER WORDS: Is it possible that: m2.bio_free(self.sslbio) m2.bio_free(self.sockbio) or self.socket.close() may hang if the client does not finish the connection completely? What is the correct way for the Server to kill a connection? set_shutdown(?) shutdown(?) Currently we close the python socket and let the M2Crypto-Connection be garbagecollected.... Thank you very much in advance.... Andre' class Connection: ... def __del__(self): try: m2.bio_free(self.sslbio) m2.bio_free(self.sockbio) except AttributeError: pass self.socket.close() On Thu, 1 Apr 2004 21:49:07 +0200 Andre Reitz wrote: > Bad news....... > > This patch doesnt work with python 2.2.3 !!!! > > something like this happens > TypeError: unbound method ...() must be called with ... instance as first argument (got nothing instead) > > > but.... > here is my patch, which should work in any case: > > (but not so efficient) > > > Greetings, Andre' > > > --- M2Crypto/SSL/Connection.py 2004-03-25 07:36:04.000000000 +0100 > +++ /home/andre/m2crypto-0.13/M2Crypto/SSL/Connection.py 2004-04-01 21:32:45.000000000 +0200 > @@ -120,34 +120,26 @@ > connection.""" > return m2.ssl_pending(self.ssl) > > - def _write_bio(self, data): > - return m2.ssl_write(self.ssl, data) > - > - def _write_nbio(self, data): > - return m2.ssl_write_nbio(self.ssl, data) > - > - def _read_bio(self, size=1024): > - if size <= 0: > - raise ValueError, 'size <= 0' > - return m2.ssl_read(self.ssl, size) > - > - def _read_nbio(self, size=1024): > + def _read(self,size=1024): > if size <= 0: > raise ValueError, 'size <= 0' > + if self._blocking: > + return m2.ssl_read(self.ssl, size) > return m2.ssl_read_nbio(self.ssl, size) > > - sendall = send = write = _write_bio > - recv = read = _read_bio > + def _write(self,data): > + if self._blocking: > + m2.ssl_write(self.ssl, data) > + return m2.ssl_write_nbio(self.ssl, data) > + > + sendall = send = write = _write > + recv = read = _read > > + _blocking=1 > def setblocking(self, mode): > """Set this connection's underlying socket to _mode_.""" > self.socket.setblocking(mode) > - if mode: > - self.send = self.write = self._write_bio > - self.recv = self.read = self._read_bio > - else: > - self.send = self.write = self._write_nbio > - self.recv = self.read = self._read_nbio > + self._blocking=mode > > def fileno(self): > return self.socket.fileno() > > > > > > > > > > > > > On Tue, 30 Mar 2004 23:55:21 +0800 > Ng Pheng Siong wrote: > > > On Tue, Mar 30, 2004 at 07:25:36PM +1200, Michael Dunstan wrote: > > > I have seen the same leak when running ZServerSSL. Had to restart the > > > server every few days. Until the following change was made for > > > setblocking: > > > > > > - self.send = self.write = self._write_bio > > > + self.send = self.write = Connection._write_bio > > > _ self.recv = self.read = self._read_bio > > > + self.recv = self.read = Connection._read_bio > > > else: > > > - self.send = self.write = self._write_nbio > > > + self.send = self.write = Connection._write_nbio > > > - self.recv = self.read = self._read_nbio > > > + self.recv = self.read = Connection._read_nbio > > > > > > Since applying the patch we have not had any memory problems for some > > > time. About 8 months now. > > > > Great! Thanks for the patch Michael. > > > > Now to roll out 0.13p1! > > > > > It is quite a simple matter to correct the headers used for the image > > > 304's in Zope. There is even an issue in the zope collector about this: > > > http://collector.zope.org/Zope/544. Looks like this incorrect handling > > > of the headers in zope is intentional to support caching in some > > > relic version of apache configured as a proxy server. > > > > Bad Zope. No biscuit for Zope. > > > > > > Cheers. > > > > -- > > Ng Pheng Siong > > > > http://firewall.rulemaker.net -+- Firewall Change Management & Version Control > > http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL > From ngps at POST1.COM Mon Apr 5 16:23:52 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Mon, 5 Apr 2004 22:23:52 +0800 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040401214907.4a1f1af3.reitz@inworks.de> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> Message-ID: <20040405142352.GA500@vista.netmemetic.com> On Thu, Apr 01, 2004 at 09:49:07PM +0200, Andre Reitz wrote: > This patch doesnt work with python 2.2.3 !!!! > > something like this happens > TypeError: unbound method ...() must be called with ... instance as first argument (got nothing instead) Doh! Ditto with Python 2.1. Bombed out in asyncore.py's poll(), although the implementations of poll() in the various versions of asyncore.py look similar enough. > but.... > here is my patch, which should work in any case: > (but not so efficient) Ok, let's see... -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Change Management & Version Control http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL From ngps at POST1.COM Mon Apr 5 16:36:37 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Mon, 5 Apr 2004 22:36:37 +0800 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040401232553.040763eb.reitz@inworks.de> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> <20040401232553.040763eb.reitz@inworks.de> Message-ID: <20040405143637.GB500@vista.netmemetic.com> On Thu, Apr 01, 2004 at 11:25:53PM +0200, Andre Reitz wrote: > I am pretty sure, that since the Connection object > gets garbage collected (and the __del__ method gets called) > the server sometimes hangs completely. > [...] > IN OTHER WORDS: > Is it possible that: > m2.bio_free(self.sslbio) > m2.bio_free(self.sockbio) > or self.socket.close() > may hang if the client does not finish the connection completely? Perhaps the server is waiting for SSL connection-close alerts, and OpenSSL isn't allowing the session to be harvested? E.g., running echo.py, see the ALERTs at the end: INFO: SSL connect: SSL negotiation finished successfully Host = vista.netmemetic.com Cipher = DHE-RSA-AES256-SHA Server = /C=SG/O=M2Crypto/CN=localhost/emailAddress=admin at server.example.dom ALERT: read: warning: close notify ALERT: write: warning: close notify Before your server calls self.socket.close(), try calling this: self.socket.set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) This says to set the SSL 'shutdown' state to "sent shutdown" and "received shutdown". The precise behaviour is described in the TLS RFC. Are your clients in Python? -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Change Management & Version Control http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL From ngps at POST1.COM Mon Apr 5 16:48:35 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Mon, 5 Apr 2004 22:48:35 +0800 Subject: [PYTHON-CRYPTO] M2Crypto improvements In-Reply-To: <406BB35B.50909@osafoundation.org> References: <406B8419.90003@osafoundation.org> <406BB35B.50909@osafoundation.org> Message-ID: <20040405144835.GC500@vista.netmemetic.com> On Wed, Mar 31, 2004 at 10:14:51PM -0800, Heikki Toivonen wrote: > * In my opinion we should get rid of the raw C ptrs in the Python object > method parameters if there is a corresponding high level Python object > available. I agree. > I think 0.13(p1) has also introduced a bug: the server3/client3 samples > used to work in 0.12 with my changes, but now with the attached patch > applied against 0.13(p1) the samples no longer work. Namely, I get the > following traceback: Heh, sorry about this. I believe this may a case where something that fails silently previously now raises an exception because of proper error checking. The problem is not in the apparently-failing call. I need to dig around a bit. > -Copyright (c) 1999-2004 Ng Pheng Siong. All rights reserved.""" > +Copyright (c) 1999-2004 Ng Pheng Siong. All rights reserved. > + > +Portions Copyright (c) 2004 Open Source Applications Foundation. > +Author: Heikki Toivonen To all who will contribute code (or have in the past), please feel free to add your copyright notices as Heikki as done here. I do ask that you agree to put your code under M2Crypto's very liberal license. Um, haven't asked Heikki yet. ;-) Heikki, okay with the licensing? Peter Teniz, who contributed most of the new X509 stuff in 0.13, has sent me more code. I think there is some overlap in functionality between Peter's code and Heikki's patches here. I'll try to spend the next several evenings integrating the patches. Thanks again. Cheers. -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Change Management & Version Control http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL From heikki at OSAFOUNDATION.ORG Mon Apr 5 19:25:11 2004 From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen) Date: Mon, 5 Apr 2004 10:25:11 -0700 Subject: [PYTHON-CRYPTO] M2Crypto improvements In-Reply-To: <20040405144835.GC500@vista.netmemetic.com> References: <406B8419.90003@osafoundation.org> <406BB35B.50909@osafoundation.org> <20040405144835.GC500@vista.netmemetic.com> Message-ID: <40719677.9070305@osafoundation.org> Ng Pheng Siong wrote: > Um, haven't asked Heikki yet. ;-) Heikki, okay with the licensing? Yes, my/OSAF changes should be covered by the M2Crypto license. -- Heikki Toivonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From reitz at INWORKS.DE Mon Apr 5 23:08:07 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Mon, 5 Apr 2004 23:08:07 +0200 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040405143637.GB500@vista.netmemetic.com> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> <20040401232553.040763eb.reitz@inworks.de> <20040405143637.GB500@vista.netmemetic.com> Message-ID: <20040405230807.1fa168c3.reitz@inworks.de> On Mon, 5 Apr 2004 22:36:37 +0800 Ng Pheng Siong wrote: > On Thu, Apr 01, 2004 at 11:25:53PM +0200, Andre Reitz wrote: > > I am pretty sure, that since the Connection object > > gets garbage collected (and the __del__ method gets called) > > the server sometimes hangs completely. > > [...] > > IN OTHER WORDS: > > Is it possible that: > > m2.bio_free(self.sslbio) > > m2.bio_free(self.sockbio) > > or self.socket.close() > > may hang if the client does not finish the connection completely? > > Perhaps the server is waiting for SSL connection-close alerts, and > OpenSSL isn't allowing the session to be harvested? > > E.g., running echo.py, see the ALERTs at the end: > > INFO: SSL connect: SSL negotiation finished successfully > Host = vista.netmemetic.com > Cipher = DHE-RSA-AES256-SHA > Server = /C=SG/O=M2Crypto/CN=localhost/emailAddress=admin at server.example.dom > ALERT: read: warning: close notify > ALERT: write: warning: close notify > > Before your server calls self.socket.close(), try calling this: > > self.socket.set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) > Ok I will try it... > This says to set the SSL 'shutdown' state to "sent shutdown" and "received > shutdown". The precise behaviour is described in the TLS RFC. > > Are your clients in Python? > yes. but the clients dont use M2Crypto. They use socket.ssl from the standard distribution. Greetings, Andre' > > -- > Ng Pheng Siong > > http://firewall.rulemaker.net -+- Firewall Change Management & Version Control > http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL From michael at ELYT.COM Tue Apr 6 04:04:48 2004 From: michael at ELYT.COM (Michael Dunstan) Date: Tue, 6 Apr 2004 14:04:48 +1200 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040405142352.GA500@vista.netmemetic.com> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> <20040405142352.GA500@vista.netmemetic.com> Message-ID: On 6/04/2004, at 2:23 AM, Ng Pheng Siong wrote: > On Thu, Apr 01, 2004 at 09:49:07PM +0200, Andre Reitz wrote: >> This patch doesnt work with python 2.2.3 !!!! >> >> something like this happens >> TypeError: unbound method ...() must be called with ... instance as >> first argument (got nothing instead) > > Doh! Ditto with Python 2.1. Bombed out in asyncore.py's poll(), > although > the implementations of poll() in the various versions of asyncore.py > look > similar enough. Doh! indeed. :-( Looks like for ZServerSSL setblocking is called by medusa core yet https_server.py calls _write_nbio and _read_nbio directly. Thus that exception is not seen when used with ZServerSSL. Well - that is my current guess for why the patch worked for me. Anyway - sorry about that. >> but.... >> here is my patch, which should work in any case: >> (but not so efficient) > > Ok, let's see... Looks a lot more careful. Lets use that. :-) From chris at CHRISBRUCE.COM Tue Apr 6 21:53:55 2004 From: chris at CHRISBRUCE.COM (Chris Bruce) Date: Tue, 6 Apr 2004 12:53:55 -0700 Subject: [PYTHON-CRYPTO] Compilation Problems Message-ID: <008501c41c10$e5606210$1f02a8c0@CBTHINKPAD> Can anyone help me with this? Can't seem to compile... root at cpanel [~/src/m2crypto-0.13]# python2.3 setup.py build running build running build_py running build_ext building '__m2crypto' extension swig -python -ISWIG -o SWIG/_m2crypto.c SWIG/_m2crypto.i gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/root/src/m2crypto-0.13/SWIG -I/usr/include -I/usr/local/include/python2.3 -c SWIG/_m2crypto.c -o build/temp.linux-i686-2.3/SWIG/_m2crypto.o -DTHREADING In file included from /usr/include/openssl/ssl.h:179, from SWIG/_m2crypto.c:863: /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory In file included from /usr/include/openssl/ssl.h:179, from SWIG/_m2crypto.c:863: /usr/include/openssl/kssl.h:134: syntax error before "krb5_enctype" /usr/include/openssl/kssl.h:136: syntax error before '*' token /usr/include/openssl/kssl.h:137: syntax error before '}' token /usr/include/openssl/kssl.h:149: syntax error before "kssl_ctx_setstring" /usr/include/openssl/kssl.h:149: syntax error before '*' token /usr/include/openssl/kssl.h:150: syntax error before '*' token /usr/include/openssl/kssl.h:151: syntax error before '*' token /usr/include/openssl/kssl.h:151: syntax error before '*' token /usr/include/openssl/kssl.h:152: syntax error before '*' token /usr/include/openssl/kssl.h:153: syntax error before "kssl_ctx_setprinc" /usr/include/openssl/kssl.h:153: syntax error before '*' token /usr/include/openssl/kssl.h:155: syntax error before "kssl_cget_tkt" /usr/include/openssl/kssl.h:155: syntax error before '*' token /usr/include/openssl/kssl.h:157: syntax error before "kssl_sget_tkt" /usr/include/openssl/kssl.h:157: syntax error before '*' token /usr/include/openssl/kssl.h:159: syntax error before "kssl_ctx_setkey" /usr/include/openssl/kssl.h:159: syntax error before '*' token /usr/include/openssl/kssl.h:161: syntax error before "context" /usr/include/openssl/kssl.h:162: syntax error before "kssl_build_principal_2" /usr/include/openssl/kssl.h:162: syntax error before "context" /usr/include/openssl/kssl.h:165: syntax error before "kssl_validate_times" /usr/include/openssl/kssl.h:165: syntax error before "atime" /usr/include/openssl/kssl.h:167: syntax error before "kssl_check_authent" /usr/include/openssl/kssl.h:167: syntax error before '*' token /usr/include/openssl/kssl.h:169: syntax error before "enctype" In file included from SWIG/_m2crypto.c:863: /usr/include/openssl/ssl.h:909: syntax error before "KSSL_CTX" /usr/include/openssl/ssl.h:931: syntax error before '}' token SWIG/_m2crypto.c: In function `sign_final': SWIG/_m2crypto.c:1925: warning: unused variable `ret' SWIG/_m2crypto.c: In function `ssl_session_read_pem': SWIG/_m2crypto.c:3443: warning: function declaration isn't a prototype SWIG/_m2crypto.c: In function `ssl_session_write_pem': SWIG/_m2crypto.c:3447: warning: function declaration isn't a prototype SWIG/_m2crypto.c: At top level: SWIG/_m2crypto.c:3497: warning: function declaration isn't a prototype SWIG/_m2crypto.c:4450: warning: function declaration isn't a prototype SWIG/_m2crypto.c:4898: warning: function declaration isn't a prototype SWIG/_m2crypto.c:5660: warning: function declaration isn't a prototype SWIG/_m2crypto.c:6481: warning: function declaration isn't a prototype SWIG/_m2crypto.c:6903: warning: function declaration isn't a prototype SWIG/_m2crypto.c:7638: warning: function declaration isn't a prototype SWIG/_m2crypto.c:9327: warning: function declaration isn't a prototype SWIG/_m2crypto.c:11392: warning: function declaration isn't a prototype SWIG/_m2crypto.c:12497: warning: function declaration isn't a prototype SWIG/_m2crypto.c:12518: warning: function declaration isn't a prototype SWIG/_m2crypto.c:13142: warning: function declaration isn't a prototype SWIG/_m2crypto.c:734: warning: `RCS_id' defined but not used error: command 'gcc' failed with exit status 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngps at POST1.COM Wed Apr 7 01:11:10 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Wed, 7 Apr 2004 07:11:10 +0800 Subject: [PYTHON-CRYPTO] Compilation Problems In-Reply-To: <008501c41c10$e5606210$1f02a8c0@CBTHINKPAD> References: <008501c41c10$e5606210$1f02a8c0@CBTHINKPAD> Message-ID: <20040406231110.GB324@vista.netmemetic.com> On Tue, Apr 06, 2004 at 12:53:55PM -0700, Chris Bruce wrote: > swig -python -ISWIG -o SWIG/_m2crypto.c SWIG/_m2crypto.i > gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/root/src/m2crypto-0.13/SWIG -I/usr/include -I/usr/local/include/python2.3 -c SWIG/_m2crypto.c -o build/temp.linux-i686-2.3/SWIG/_m2crypto.o -DTHREADING > In file included from /usr/include/openssl/ssl.h:179, > from SWIG/_m2crypto.c:863: > /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory No such file or directory. > In file included from /usr/include/openssl/ssl.h:179, > from SWIG/_m2crypto.c:863: > /usr/include/openssl/kssl.h:134: syntax error before "krb5_enctype" > [...] These syntax errors are presumably due to the failure to include the missing krb5.h. IIRC, by default OpenSSL does not build with Kerberos cipher suites. Yours seems to be, yet your system appears to not have Kerberos. You might want to fix your OpenSSL installation first. HTH. Cheers. -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Change Management & Version Control http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL From ngps at POST1.COM Thu Apr 8 03:07:24 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Thu, 8 Apr 2004 09:07:24 +0800 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040401214907.4a1f1af3.reitz@inworks.de> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> Message-ID: <20040408010724.GD632@vista.netmemetic.com> On Thu, Apr 01, 2004 at 09:49:07PM +0200, Andre Reitz wrote: > here is my patch, which should work in any case: > (but not so efficient) Is it easy to induce/observe the leak? I think one possible cheap way to fix the cyclical references is to do this self._write_bio = None self._write_nbio = None self._read_bio = None self._read_nbio = None at a strategic spot, perhaps in close(). This gets rid of the mode test at every invocation of read/write/send/recv. What do you think? -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Change Management & Version Control http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL From reitz at INWORKS.DE Thu Apr 8 11:06:18 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Thu, 8 Apr 2004 11:06:18 +0200 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040408010724.GD632@vista.netmemetic.com> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> <20040408010724.GD632@vista.netmemetic.com> Message-ID: <20040408110618.1197b30d.reitz@inworks.de> On Thu, 8 Apr 2004 09:07:24 +0800 Ng Pheng Siong wrote: > On Thu, Apr 01, 2004 at 09:49:07PM +0200, Andre Reitz wrote: > > here is my patch, which should work in any case: > > (but not so efficient) > > Is it easy to induce/observe the leak? > > I think one possible cheap way to fix the cyclical references is to do this > > self._write_bio = None > self._write_nbio = None > self._read_bio = None > self._read_nbio = None > > at a strategic spot, perhaps in close(). This gets rid of the mode test at > every invocation of read/write/send/recv. > > What do you think? > not really a good idea. this would work for myself, but perheps if a thread exits with an exception and doesnt call close... there would be the same problem.... Greetings Andre' > -- > Ng Pheng Siong > > http://firewall.rulemaker.net -+- Firewall Change Management & Version Control > http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL -- __________________________________________________________________________ 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 m24me at KATEHOK.HOMEIP.NET Tue Apr 13 02:53:36 2004 From: m24me at KATEHOK.HOMEIP.NET (Igor Belyi) Date: Mon, 12 Apr 2004 20:53:36 -0400 Subject: [PYTHON-CRYPTO] Adding functionality into DSA. Message-ID: <1081817615.1495.11.camel@leonid> I've added some functionality into DSA so that it can now sign, verify, and save/retrieve public and private keys in/from files. To be honest, it was just copy/paste from the RSA with slight variations. But at least now you can use DSA for some simple security purposes. Patch is on top of m2crypto-0.13.1 Cheers, Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: m2crypto-0.13.1-DSA.patch Type: text/x-patch Size: 6064 bytes Desc: not available URL: From reitz at INWORKS.DE Wed Apr 14 11:21:17 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Wed, 14 Apr 2004 11:21:17 +0200 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040405230807.1fa168c3.reitz@inworks.de> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> <20040401232553.040763eb.reitz@inworks.de> <20040405143637.GB500@vista.netmemetic.com> <20040405230807.1fa168c3.reitz@inworks.de> Message-ID: <20040414112117.5497d9ba.reitz@inworks.de> On Mon, 5 Apr 2004 23:08:07 +0200 Andre Reitz wrote: > On Mon, 5 Apr 2004 22:36:37 +0800 > Ng Pheng Siong wrote: > > > On Thu, Apr 01, 2004 at 11:25:53PM +0200, Andre Reitz wrote: > > > I am pretty sure, that since the Connection object > > > gets garbage collected (and the __del__ method gets called) > > > the server sometimes hangs completely. > > > [...] > > > IN OTHER WORDS: > > > Is it possible that: > > > m2.bio_free(self.sslbio) > > > m2.bio_free(self.sockbio) > > > or self.socket.close() > > > may hang if the client does not finish the connection completely? > > > > Perhaps the server is waiting for SSL connection-close alerts, and > > OpenSSL isn't allowing the session to be harvested? > > > > E.g., running echo.py, see the ALERTs at the end: > > > > INFO: SSL connect: SSL negotiation finished successfully > > Host = vista.netmemetic.com > > Cipher = DHE-RSA-AES256-SHA > > Server = /C=SG/O=M2Crypto/CN=localhost/emailAddress=admin at server.example.dom > > ALERT: read: warning: close notify > > ALERT: write: warning: close notify > > > > Before your server calls self.socket.close(), try calling this: > > > > self.socket.set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) > > > Ok I will try it... > > > This says to set the SSL 'shutdown' state to "sent shutdown" and "received > > shutdown". The precise behaviour is described in the TLS RFC. > > > > Are your clients in Python? > > > yes. but the clients dont use M2Crypto. > They use socket.ssl from the standard distribution. > > now I have tried it: calling set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) before destructor __del__ comes stops my multi-threaded server from hanging. if I do not call set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) the complete server sometimes hangs in m2.bio_free(self.sslbio) of Connection.__del__ Why? does bio_free still want to communicate with the client? (which is already disconnected?) Thank you very much for your help. Greetings, Andre' > > > > > -- > > Ng Pheng Siong > > > > http://firewall.rulemaker.net -+- Firewall Change Management & Version Control > > http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL -- __________________________________________________________________________ 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 valeriy.pogrebitskiy at DB.COM Wed Apr 14 16:00:52 2004 From: valeriy.pogrebitskiy at DB.COM (Valeriy Pogrebitskiy) Date: Wed, 14 Apr 2004 10:00:52 -0400 Subject: [PYTHON-CRYPTO] M2Crypto Package Message-ID: Everyone, My group is using custom-built Python 2.2.1 package (which does not include Makefile, and does not have "distutils"). Thus, we are unable to compile and install any of the third-party Python modules - unless we can find pre-built (pre-compiled) packages. Currently, we need to get M2Crypto package. Does anyone know where I can get pre-built (pre-compiled) version of this package using Python 2.2.1 and SunOS 5.6 ? Valeriy Pogrebitskiy E-Mail: vpogrebi at iname.com Work: (908) 608-3137 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From ngps at POST1.COM Thu Apr 15 02:48:43 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Thu, 15 Apr 2004 08:48:43 +0800 Subject: [PYTHON-CRYPTO] Adding functionality into DSA. In-Reply-To: <1081817615.1495.11.camel@leonid> References: <1081817615.1495.11.camel@leonid> Message-ID: <20040415004843.GB715@vista.netmemetic.com> On Mon, Apr 12, 2004 at 08:53:36PM -0400, Igor Belyi wrote: > I've added some functionality into DSA so that it can now sign, verify, > and save/retrieve public and private keys in/from files. Thanks. I'll fold that into the next release. Cheers. -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Change Management & Version Control http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers From ngps at POST1.COM Thu Apr 15 02:57:07 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Thu, 15 Apr 2004 08:57:07 +0800 Subject: [PYTHON-CRYPTO] M2Crypto Package In-Reply-To: References: Message-ID: <20040415005707.GC715@vista.netmemetic.com> On Wed, Apr 14, 2004 at 10:00:52AM -0400, Valeriy Pogrebitskiy wrote: > My group is using custom-built Python 2.2.1 package (which does not > include Makefile, and does not have "distutils"). Thus, we are unable to > compile and install any of the third-party Python modules - unless we can > find pre-built (pre-compiled) packages. Currently, we need to get > M2Crypto package. Does SWIG/Makefile.py22 not do what you need? Unless your custom Python packaging renders the standard Python include files useless, you should be able to build using that makefile. By convention Distutils installs into /site-packages/M2Crypto. You can do that by hand. BTW, I worked in APHO in 99/00. (Kerberos, smart cards, etc.) Nice to see you guys using this. ;-) Cheers. -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Change Management & Version Control http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers From ngps at POST1.COM Thu Apr 15 02:48:04 2004 From: ngps at POST1.COM (Ng Pheng Siong) Date: Thu, 15 Apr 2004 08:48:04 +0800 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040414112117.5497d9ba.reitz@inworks.de> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> <20040401232553.040763eb.reitz@inworks.de> <20040405143637.GB500@vista.netmemetic.com> <20040405230807.1fa168c3.reitz@inworks.de> <20040414112117.5497d9ba.reitz@inworks.de> Message-ID: <20040415004804.GA715@vista.netmemetic.com> On Wed, Apr 14, 2004 at 11:21:17AM +0200, Andre Reitz wrote: > calling > set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) > before destructor __del__ comes > stops my multi-threaded server from hanging. > > if I do not call > set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) > the complete server sometimes hangs in > m2.bio_free(self.sslbio) of Connection.__del__ > > Why? > does bio_free still want to communicate with the client? > (which is already disconnected?) M2Crypto's bio_free calls OpenSSL API BIO_free calls OpenSSL internal ssl_free calls OpenSSL API SSL_shutdown and others. SSL_shutdown tears down the SSL connection, including handling the closure alert messages I mentioned in the earlier post. The statement set_shutdown(...) tells OpenSSL to not send nor wait for the closure alerts. The alerts are actually a security feature that defends against *truncation attacks*. I've been thinking of creating, say, classes SSL.SContext and SSL.SConnection that presents a simpler API, with more defaults and fewer methods. OTOH, I'm reluctant to hide any security feature that inconveniences the app programmer under the hood because I think that's saying, "Trust me, I've figured this out and have decided for you what you need to know." Trust me you can ;-) but decide for yourself you should. What does the list think? -- Ng Pheng Siong http://firewall.rulemaker.net -+- Firewall Change Management & Version Control http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers From reitz at INWORKS.DE Thu Apr 15 11:13:58 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Thu, 15 Apr 2004 11:13:58 +0200 Subject: [PYTHON-CRYPTO] Memoryleak in SSL.Connection In-Reply-To: <20040415004804.GA715@vista.netmemetic.com> References: <703FA3DD-821B-11D8-A5A3-000393B53F20@elyt.com> <20040330155521.GB446@vista.netmemetic.com> <20040401214907.4a1f1af3.reitz@inworks.de> <20040401232553.040763eb.reitz@inworks.de> <20040405143637.GB500@vista.netmemetic.com> <20040405230807.1fa168c3.reitz@inworks.de> <20040414112117.5497d9ba.reitz@inworks.de> <20040415004804.GA715@vista.netmemetic.com> Message-ID: <20040415111358.35198ca5.reitz@inworks.de> On Thu, 15 Apr 2004 08:48:04 +0800 Ng Pheng Siong wrote: > On Wed, Apr 14, 2004 at 11:21:17AM +0200, Andre Reitz wrote: > > calling > > set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) > > before destructor __del__ comes > > stops my multi-threaded server from hanging. > > > > if I do not call > > set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) > > the complete server sometimes hangs in > > m2.bio_free(self.sslbio) of Connection.__del__ > > > > Why? > > does bio_free still want to communicate with the client? > > (which is already disconnected?) > > M2Crypto's bio_free calls OpenSSL API BIO_free calls OpenSSL internal > ssl_free calls OpenSSL API SSL_shutdown and others. > > SSL_shutdown tears down the SSL connection, including handling the closure > alert messages I mentioned in the earlier post. > > The statement set_shutdown(...) tells OpenSSL to not send nor wait for the > closure alerts. > > The alerts are actually a security feature that defends against *truncation > attacks*. > > I've been thinking of creating, say, classes SSL.SContext and > SSL.SConnection that presents a simpler API, with more defaults and fewer > methods. > > OTOH, I'm reluctant to hide any security feature that inconveniences the > app programmer under the hood because I think that's saying, "Trust me, > I've figured this out and have decided for you what you need to know." > > Trust me you can ;-) but decide for yourself you should. > > What does the list think? > Well I think that M2Crypto is ok as it is. The only change I would make is: add: set_shutdown(SSL.SSL_SENT_SHUTDOWN|SSL.SSL_RECEIVED_SHUTDOWN) to Connection.__del__ (If the application-Programmer doesn't call close() or shutdown() in a correct way) I think that if the __del__ method gets called, and the connection isn't really already "shutdown" the worst thing that could happen, is that __del__ doesn't succeed in any case. My approach would be to regard the __del__ method as some kind of a "disconnect which always succeeds without problems or errors"-method. Greetings, Andre' > -- > Ng Pheng Siong > > http://firewall.rulemaker.net -+- Firewall Change Management & 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 m24me at KATEHOK.HOMEIP.NET Fri Apr 16 01:49:38 2004 From: m24me at KATEHOK.HOMEIP.NET (Igor Belyi) Date: Thu, 15 Apr 2004 19:49:38 -0400 Subject: [PYTHON-CRYPTO] Adding functionality into DSA. In-Reply-To: <20040415004843.GB715@vista.netmemetic.com> References: <1081817615.1495.11.camel@leonid> <20040415004843.GB715@vista.netmemetic.com> Message-ID: <1082072978.1451.97.camel@leonid> On Wed, 2004-04-14 at 20:48, Ng Pheng Siong wrote: > Thanks. I'll fold that into the next release. It appears that my copy&paste from RSA didn't went far enough. Here's a patch on top of my previous one. I also took the liberty and made 'verify' method symmetrical to the 'sign', so that the following command can be used for signature verification: assert dsa.verify(data, dsa.sign(data)) If this is inappropriate (somebody depends on the old set of arguments, for example), just delete the corresponding part of the patch and update the test_dsa.py. Cheers, Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: m2crypto-0.13.1-DSA-2.patch Type: text/x-patch Size: 4894 bytes Desc: not available URL: From reitz at INWORKS.DE Mon Apr 19 11:57:43 2004 From: reitz at INWORKS.DE (Andre Reitz) Date: Mon, 19 Apr 2004 11:57:43 +0200 Subject: [PYTHON-CRYPTO] Question about M2Crypto Version 0.13 Message-ID: <20040419115743.1ad3f96f.reitz@inworks.de> Hi all, I had a problem with M2Crypto < 0.13: Python multithreaded server using m2crypto with nonblocking SSL.Connections communicating with windowsclient with socket.ssl objects. If windowsclient got killed, SSL.Connection.read returned "" on server side. since M2Crypto 0.13 the server returns an error. The new behaviour is correct. Elder Versions of M2Crypto didn't notice that the client is gone. Question: Was this a bug which got fixed in Version 0.13? 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 carnesm at LUCENT.COM Tue Apr 27 22:24:26 2004 From: carnesm at LUCENT.COM (CARNES, MARK E (MARK)) Date: Tue, 27 Apr 2004 15:24:26 -0500 Subject: [PYTHON-CRYPTO] Trouble building m2crypto Message-ID: <17D8724A2A8D9542B2B8AE546B9E5BBC01628007@AZ4315EXCH001U> I have been trying to build m2crypto, but it is not linking successfully, and I was hoping someone on the list may have overcome a similiar problem. I am compiling on Solaris 8 with gcc 3.3.2, python 2.2.3, swig 1.3.21, openssl 0.9.7d Everything runs ok on the step: python setup.py build It dies while trying to link and produces the following error: gcc -shared build/temp.solaris-2.8-sun4u-2.2/_m2crypto.o -L/usr/lib -lssl -lcrypto -o build/lib.solaris-2.8-sun4u-2.2/M2Crypto/__m2crypto.so Text relocation remains referenced against symbol offset in file 0x3cc /usr/lib/libssl.a(s3_lib.o) 0x3d0 /usr/lib/libssl.a(s3_lib.o) 0x3d4 /usr/lib/libssl.a(s3_lib.o) ... ... Anyone know why I'd get these link errors?