From mengelhart at katahdinsoftware.com Sun Nov 3 19:04:13 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Sun, 3 Nov 2002 13:04:13 -0500 Subject: sample code online In-Reply-To: <3DC55E6A.4010005@stroeder.com> Message-ID: Thanks for the changes and comments. I'll edit those tonight and upload. As for ldap.async.List are you suggesting that we'll have some more user friendly wrappers for python-ldap? Is that something that people are working on? I think that would be a great thing if we could get an easier to use wrapper around the low-level calls. Cheers Mike On Sunday, November 3, 2002, at 12:35 PM, Michael Str?der wrote: > Michael Engelhart wrote: >> I just put a very simple set of python-ldap sample code that shows >> searching a directory, binding to a directory, and deleting entries: >> http://homepage.mac.com/mengelhart/python-ldap-samples.html > > Thanks for contributing that. I've added a link to this page to > http://python-ldap.sourceforge.net/docs.shtml . > > Some comments: > > As default an LDAPv2 connection is made by the OpenLDAP client libs. > Therefore you have to explicitly set the attribute protocol_version to > use LDAPv3. Personally I prefer to use: > > l.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3) > > This is especially true in the search example: > > -------------------- snip ------------------ > ## first you must open a connection to the server > try: > l = ldap.open("127.0.0.1") > ## searching doesn't require a bind > except ldap.LDAPError, e: > print e > # handle error however you like > -------------------- snip ------------------ > > Here you state that a BindRequest is not needed before the > SearchRequest. This is only true for LDAPv3! Most times an LDAPv2 > server will give you back ldap.PROTOCOL_ERROR (or behave odd ;-). > > It should read: > > -------------------- snip ------------------ > ## first you must open a connection to the server > try: > l = ldap.open("127.0.0.1") > l.protocol_version = ldap.VERSION3 > ## with LDAPv3 searching doesn't require a bind > except ldap.LDAPError, e: > print e > # handle error however you like > -------------------- snip ------------------ > > Unfortunately if LDAPv3 is not supported you will get an error at the > point where you send the first LDAPRequest (the SearchRequest in your > example). > > Now one might wonder how to properly "negotiate" the LDAP protocol > version. Well, check out how it's done > ldap.ldapobject.SmartLDAPObject. This is not ready for prime time yet > but should give you some inspiration. Please test! > > Your async search example is a good starting point to lead over to > deploying class ldap.async.List. ;-) > > Well, everybody is encouraged to dig into Demo/ anyway. > > Ciao, Michael. > From michael at stroeder.com Sun Nov 3 19:14:37 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 03 Nov 2002 19:14:37 +0100 Subject: ldap.async (was: sample code online) References: Message-ID: <3DC5678D.3010705@stroeder.com> Michael Engelhart wrote: > > As for ldap.async.List are you suggesting that we'll have some more user > friendly wrappers for python-ldap? Well, I developed it for web2ldap and some of my commercial projects and contributed it to python-ldap. ldap.async solves some real-word problems for me: - Stream processing of large result sets (ldap.async.AsyncSearchHandler) - Grab partial search results (ldap.async.List) - Write large result sets to file object (ldap.async.FileWriter), e.g. produce LDIF with ldap.async.LDIFWriter. There's also some potential with deriving classes from ldap.ldapobject.LDAPObject (mainly SimpleLDAPObject): Automatic fail-over, load-balancing. E.g. I'm using ldap.ldapobject.ReconnectLDAPObject in web2ldap to work around Domino/LDAP dropping LDAP connections quite frequently. But I did not make up my mind so far about a really nice and cleanly designed class structure. > Is that something that people are > working on? At the moment I'm the only one... Ciao, Michael. ------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Python-LDAP-dev mailing list Python-LDAP-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/python-ldap-dev From z3p at TWISTEDMATRIX.COM Sun Nov 10 18:13:37 2002 From: z3p at TWISTEDMATRIX.COM (Paul Swartz) Date: Sun, 10 Nov 2002 12:13:37 -0500 Subject: [PYTHON-CRYPTO] Erasing strings from memory? Message-ID: <3DCE4D71.3235.6BA6F5@localhost> I'm working on a SSH client/server for Twisted, and some of the things the client needs to work with are passwords both for login and for private keys, and then the decrypted keys. Obviously, storing these in memory leads to the possibility of acessing them and thereby compromising the user. Is there a way to overwrite the data, or otherwise erase it from memory? -p -- Paul Swartz (o_ http://twistedmatrix.com/users/z3p.twistd/ //\ z3p at twistedmatrix.com V_/_ AIM: Z3Penguin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at DATAPOWER.COM Sun Nov 10 19:08:58 2002 From: rsalz at DATAPOWER.COM (Rich Salz) Date: Sun, 10 Nov 2002 13:08:58 -0500 Subject: [PYTHON-CRYPTO] Erasing strings from memory? In-Reply-To: <3DCE4D71.3235.6BA6F5@localhost> Message-ID: The following module zero's out a python string. hope it helps. # --cut here-- #! /bin/sh # To unshar, remove everything before the "cut here" line # and feed the result to /bin/sh sed -e 's/^X//' >zerostr.c <<'FUNKY_STUFF' X/* X** X** To compile: X gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.2 -c zerostr.c X gcc -shared zerostr.o -o zerostr.so X** To use: X a = '1234' X import zerostr X zerostr.zero(a) X print a X*/ X#include X Xstatic PyObject* Xzerostr_zero(PyObject* self, PyObject* args) X{ X PyObject* t; X char* p; X int i; X X if (!PyArg_ParseTuple(args, "O", &t)) X return NULL; X if (!PyString_Check(t)) { X Py_DECREF(t); X PyErr_SetString(PyExc_TypeError, "Must be a string"); X return NULL; X } X i = PyString_GET_SIZE(t); X p = PyString_AS_STRING(t); X while (--i >= 0) X *p++ = '\0'; X Py_DECREF(t); X Py_INCREF(Py_None); X return Py_None; X} X Xstatic PyMethodDef zerostrMethods[] = { X { "zero", zerostr_zero, METH_VARARGS, X "Fill a string with NUL bytes."}, X { NULL, NULL, 0, NULL } X}; X X Xvoid Xinitzerostr(void) X{ X (void)Py_InitModule("zerostr", zerostrMethods); X} FUNKY_STUFF sed -e 's/^X//' >setup.py <<'FUNKY_STUFF' X Xfrom distutils.core import setup, Extension X Xzm = Extension('zerostr', sources = ['zerostr.c']) X Xsetup(name='ZeroStrPackage', X version='1.0', X description="Sample package zero'ing a string", X ext_modules = [ zm ]) X FUNKY_STUFF From mal at LEMBURG.COM Mon Nov 11 09:30:42 2002 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Mon, 11 Nov 2002 09:30:42 +0100 Subject: [PYTHON-CRYPTO] Erasing strings from memory? References: Message-ID: <3DCF6AB2.4020905@lemburg.com> Rich Salz wrote: > The following module zero's out a python string. > hope it helps. Be careful with this: Python strings are immutable and some are shared. The code you gave below can result in a completely broken Python interpreter. > # --cut here-- > #! /bin/sh > # To unshar, remove everything before the "cut here" line > # and feed the result to /bin/sh > sed -e 's/^X//' >zerostr.c <<'FUNKY_STUFF' > X/* > X** > X** To compile: > X gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.2 -c zerostr.c > X gcc -shared zerostr.o -o zerostr.so > X** To use: > X a = '1234' > X import zerostr > X zerostr.zero(a) > X print a > X*/ > X#include > X > Xstatic PyObject* > Xzerostr_zero(PyObject* self, PyObject* args) > X{ > X PyObject* t; > X char* p; > X int i; > X > X if (!PyArg_ParseTuple(args, "O", &t)) > X return NULL; > X if (!PyString_Check(t)) { > X Py_DECREF(t); > X PyErr_SetString(PyExc_TypeError, "Must be a string"); > X return NULL; > X } > X i = PyString_GET_SIZE(t); > X p = PyString_AS_STRING(t); > X while (--i >= 0) > X *p++ = '\0'; > X Py_DECREF(t); > X Py_INCREF(Py_None); > X return Py_None; > X} > X > Xstatic PyMethodDef zerostrMethods[] = { > X { "zero", zerostr_zero, METH_VARARGS, > X "Fill a string with NUL bytes."}, > X { NULL, NULL, 0, NULL } > X}; > X > X > Xvoid > Xinitzerostr(void) > X{ > X (void)Py_InitModule("zerostr", zerostrMethods); > X} > FUNKY_STUFF > sed -e 's/^X//' >setup.py <<'FUNKY_STUFF' > X > Xfrom distutils.core import setup, Extension > X > Xzm = Extension('zerostr', sources = ['zerostr.c']) > X > Xsetup(name='ZeroStrPackage', > X version='1.0', > X description="Sample package zero'ing a string", > X ext_modules = [ zm ]) > X > FUNKY_STUFF -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From rsalz at DATAPOWER.COM Mon Nov 11 12:47:15 2002 From: rsalz at DATAPOWER.COM (Rich Salz) Date: Mon, 11 Nov 2002 06:47:15 -0500 Subject: [PYTHON-CRYPTO] Erasing strings from memory? In-Reply-To: <3DCF6AB2.4020905@lemburg.com> Message-ID: > Be careful with this: Python strings are immutable and some > are shared. The code you gave below can result in a > completely broken Python interpreter. Good point. Check that refcount==1 before actual memset. /r$ From jeremy at alum.mit.edu Tue Nov 12 18:53:57 2002 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Tue, 12 Nov 2002 12:53:57 -0500 Subject: [PYTHON-CRYPTO] Erasing strings from memory? In-Reply-To: <3DCFBA97.20468.7F172@localhost> References: <3DCF6AB2.4020905@lemburg.com> <3DCFBA97.20468.7F172@localhost> Message-ID: <15825.16437.547414.422476@slothrop.zope.com> >>>>> "PS" == Paul Swartz writes: >> Good point. Check that refcount==1 before actual memset. /r$ PS> I don't know. I liked that the old code cleared all the PS> references to the string so I don't have to worry about PS> misc. references sitting around keeping this string in memory. PS> Does python really care if strings change on it? Yes. Python depends in a lot of ways on strings being immutable. If the string gets stuffed in a dictionary and you modify it, you'll get unpredictable results. The string can also be interned. You can't modify a string in the intern table. I think the test for refcount==1 isn't sufficient. I wrote a zap module a couple of years ago that did much the same thing. (Not sure what happened to the code.) It's almost impossible to call a function to zap a string and have it's refcount be 1. The mere fact that it is on the call stack will add at least one reference. I think the solution is to verify that it is not interned (ob_sstate), then recalculate the hash after zapping the string. Jeremy From z3p at TWISTEDMATRIX.COM Tue Nov 12 19:04:22 2002 From: z3p at TWISTEDMATRIX.COM (Paul Swartz) Date: Tue, 12 Nov 2002 12:04:22 -0600 Subject: [PYTHON-CRYPTO] Erasing strings from memory? In-Reply-To: <15825.16437.547414.422476@slothrop.zope.com> References: <3DCF6AB2.4020905@lemburg.com> <3DCFBA97.20468.7F172@localhost> <15825.16437.547414.422476@slothrop.zope.com> Message-ID: <20021112180422.GA29637@pyramid.twistedmatrix.com> On Tue, Nov 12, 2002 at 12:53:57PM -0500, Jeremy Hylton wrote: > PS> I don't know. I liked that the old code cleared all the > PS> references to the string so I don't have to worry about > PS> misc. references sitting around keeping this string in memory. > PS> Does python really care if strings change on it? > > Yes. Python depends in a lot of ways on strings being immutable. If > the string gets stuffed in a dictionary and you modify it, you'll get > unpredictable results. The string can also be interned. You can't > modify a string in the intern table. None of these strings will be a dictionary key. They're either incorporated into a hash, or parsed into an alternate form. As for interning, will they be interned if they're not a dictionary key nor do I manually intern them? > I think the solution is to verify that it is not interned (ob_sstate), > then recalculate the hash after zapping the string. This sounds like a good idea. Thanks for all the help/advice. -p -- Paul Swartz (o_ http://www.twistedmatrix.com/users/z3p.twistd/ _o) //\ z3p at twistedmatrix.com /\\ V_/_ AIM: z3penguin _\_V-> Democracy is the recurrent suspicion that more than half the people are right more than half of the time. From jeremy at alum.mit.edu Tue Nov 12 19:15:43 2002 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Tue, 12 Nov 2002 13:15:43 -0500 Subject: [PYTHON-CRYPTO] Erasing strings from memory? In-Reply-To: <20021112180422.GA29637@pyramid.twistedmatrix.com> References: <3DCF6AB2.4020905@lemburg.com> <3DCFBA97.20468.7F172@localhost> <15825.16437.547414.422476@slothrop.zope.com> <20021112180422.GA29637@pyramid.twistedmatrix.com> Message-ID: <15825.17743.406277.559642@slothrop.zope.com> >>>>> "PS" == Paul Swartz writes: PS> On Tue, Nov 12, 2002 at 12:53:57PM -0500, Jeremy Hylton wrote: I PS> don't know. I liked that the old code cleared all the PS> references to the string so I don't have to worry about PS> misc. references sitting around keeping this string in memory. PS> Does python really care if strings change on it? >> >> Yes. Python depends in a lot of ways on strings being immutable. >> If the string gets stuffed in a dictionary and you modify it, >> you'll get unpredictable results. The string can also be >> interned. You can't modify a string in the intern table. PS> None of these strings will be a dictionary key. They're either PS> incorporated into a hash, or parsed into an alternate form. As PS> for interning, will they be interned if they're not a dictionary PS> key nor do I manually intern them? We know they're not supposed to be used that way, but there's no way to guarantee it. Incautious use of this code could lead to bizarre, impossible to understand behavior. I think we both know that and are willing to live with it. Jeremy From z3p at TWISTEDMATRIX.COM Tue Nov 19 03:35:20 2002 From: z3p at TWISTEDMATRIX.COM (Paul Swartz) Date: Mon, 18 Nov 2002 21:35:20 -0500 Subject: [PYTHON-CRYPTO] RSA/DSA in C Message-ID: <3DD95D18.3053.181FFEB@localhost> Over the weekend, I wrote up modules using gmp to implement RSA and DSA in C. These work with the current Crypto.PublicKey.pubkey interface, and pass the tests. I'm submitting them to you all to look at, and if no one has any complaints, I'll commit them to the repository. The benchmarks I wrote (5000 encrypts/decrypts for RSA, 500 signs/verifys for DSA) show a significant speedup, especially for DSA. RSA went from 10.7s to 2.1s, and DSA went from 76.7s to 2.6s. (attached: Crypto/setup.py.diff, Crypto/PublicKey/RSA.py.diff, Crypto/PublicKey/DSA.py.diff, , Crypto/src/_rsa.c, Crypto/src/_dsa.c) -p -- Paul Swartz (o_ http://twistedmatrix.com/users/z3p.twistd/ //\ z3p at twistedmatrix.com V_/_ AIM: Z3Penguin -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: _dsa.c Date: 17 Nov 2002, 23:57 Size: 7026 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: _dsa.c Type: application/octet-stream Size: 7018 bytes Desc: not available URL: -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: _rsa.c Date: 17 Nov 2002, 21:39 Size: 7124 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: _rsa.c Type: application/octet-stream Size: 7118 bytes Desc: not available URL: -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: setup.py.diff Date: 18 Nov 2002, 18:20 Size: 1007 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.py.diff Type: application/octet-stream Size: 975 bytes Desc: not available URL: -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: DSA.py.diff Date: 18 Nov 2002, 21:30 Size: 1900 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: DSA.py.diff Type: application/octet-stream Size: 1909 bytes Desc: not available URL: -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: RSA.py.diff Date: 18 Nov 2002, 21:34 Size: 2791 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: RSA.py.diff Type: application/octet-stream Size: 2788 bytes Desc: not available URL: From z3p at TWISTEDMATRIX.COM Wed Nov 20 01:10:10 2002 From: z3p at TWISTEDMATRIX.COM (Paul Swartz) Date: Tue, 19 Nov 2002 19:10:10 -0500 Subject: [PYTHON-CRYPTO] RSA/DSA in C, part deux Message-ID: <3DDA8C92.6933.FA394F@localhost> New versions of the C modules attached, the old ones didn't build on all C compilers (thank you - pedantic). -p -- Paul Swartz (o_ http://twistedmatrix.com/users/z3p.twistd/ //\ z3p at twistedmatrix.com V_/_ AIM: Z3Penguin -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: _rsa.c Date: 19 Nov 2002, 19:08 Size: 7137 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: _rsa.c Type: application/octet-stream Size: 7131 bytes Desc: not available URL: -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: _dsa.c Date: 19 Nov 2002, 19:08 Size: 7184 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: _dsa.c Type: application/octet-stream Size: 7177 bytes Desc: not available URL: