From robert.meany at gmail.com Sat Apr 26 20:24:29 2014 From: robert.meany at gmail.com (Robert Meany) Date: Sat, 26 Apr 2014 14:24:29 -0400 Subject: [python-ldap] Modifying AD ntSecurityDescriptor directly from python-ldap? Message-ID: Is this possible? If I try to pull ntSecurityDescriptor as an attribute from an AD object, I get nothing back. I need to make changes to this attribute in order to set the 'user cannot change password' flag on our user accounts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Sun Apr 27 01:39:19 2014 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 27 Apr 2014 01:39:19 +0200 Subject: [python-ldap] Modifying AD ntSecurityDescriptor directly from python-ldap? In-Reply-To: References: Message-ID: <535C43A7.3040500@stroeder.com> Robert Meany wrote: > Is this possible? If I try to pull ntSecurityDescriptor as an attribute > from an AD object, I get nothing back. You have to request 'ntSecurityDescriptor' explicitly. > I need to make changes to this > attribute in order to set the 'user cannot change password' flag on our > user accounts. Are you sure that you don't want to tweak 'userAccountControl' on the user's entry for that? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From mehaase at gmail.com Tue Apr 29 05:50:00 2014 From: mehaase at gmail.com (Mark E. Haase) Date: Mon, 28 Apr 2014 23:50:00 -0400 Subject: [python-ldap] Issue with TLS contexts... Message-ID: I'm having an issue with TLS in python-ldap. I can get a few basic use cases working, but it appears that it's not possible to change some TLS context parameters at runtime after they have initially been set. Here's a test case i've reproduced: 1 import ldap 2 import os 3 4 url = "ldaps://***********************:636/" 5 username = "cn=admin,dc=****************,dc=net" 6 password = "*************" 7 8 # ldap.set_option( ldap.OPT_DEBUG_LEVEL, 255 ) 9 10 base_path = os.path.dirname(os.path.realpath(__file__)) 11 ldap_handle = ldap.initialize(url) 12 13 # ldap.set_option(ldap.OPT_X_TLS_NEWCTX, 0) 14 ldap.set_option(ldap.OPT_X_TLS, ldap.OPT_X_TLS_DEMAND) 15 ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_DEMAND) 16 ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, os.path.join(base_path, "badca")) 17 18 print("OPT_X_TLS", ldap.get_option(ldap.OPT_X_TLS)) 19 print("OPT_X_TLS_REQUIRE_CERT", ldap.get_option(ldap.OPT_X_TLS_REQUIRE_CERT)) 20 print("OPT_X_TLS_CACERTFILE", ldap.get_option(ldap.OPT_X_TLS_CACERTFILE)) 21 22 try: 23 print("#" * 20) + "SIMPLE BIND #1" + ("#" * 20) 24 ldap_handle.simple_bind_s(username, password) 25 print("Success!") 26 except ldap.SERVER_DOWN: 27 print("Caught 'server down' during bind #1.") 28 29 ldap_handle2 = ldap.initialize(url) 30 ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, os.path.join(base_path, "goodca")) 31 32 print("OPT_X_TLS", ldap.get_option(ldap.OPT_X_TLS)) 33 print("OPT_X_TLS_REQUIRE_CERT", ldap.get_option(ldap.OPT_X_TLS_REQUIRE_CERT)) 34 print("OPT_X_TLS_CACERTFILE", ldap.get_option(ldap.OPT_X_TLS_CACERTFILE)) 35 36 try: 37 print("#" * 20) + "SIMPLE BIND #2" + ("#" * 20) 38 ldap_handle2.simple_bind_s(username, password) 39 print("Success!") 40 except ldap.SERVER_DOWN: 41 print("Caught 'server down' during bind #2.") Note that I have two CA certificate files (lines 16 and 30). One is "goodca" and it contains the server's actual CA certificate. The other is called "badca" and it contains some other random CA certificate. If I try to create 2 instances and the first one uses the bad ca, then the second one also uses the bad ca and they both fail! If I transpose lines 16 and 30, then they both use the good ca and both connections succeed! In short, it appears that once CACERTFILE has been set, it's not possible to change it. The example above is highly contrived, because I'm trying to isolate the issue. But my use case is a web application where an end user can provide a CA certificate, so it's not ideal if the entire web server has to be restarted every time the user provides a new CA certificate. (Also I'd like to be able to support multiple LDAP servers in the same process.) Is this intended behavior? Is it a bug? Should I be doing something different? Notice on line 13 I had experimented with creating a new TLS context, but this parameter isn't document well in OpenLDAP or python-ldap, so I'm not exactly sure what argument to pass to it. OpenLDAP has a function to directly set a TLS context, but that doesn't appear to have been translated into python-ldap. I also tried setting options directly on the ldap_handle, but some options (such as CACERTFILE) don't seem to apply to ldap_handle. Any feedback would be greatly appreciated. I've been staring at python-ldap for about 10 hours today :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Apr 29 08:38:30 2014 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Apr 2014 08:38:30 +0200 Subject: [python-ldap] Issue with TLS contexts... In-Reply-To: References: Message-ID: <535F48E6.3020600@stroeder.com> Mark E. Haase wrote: > I'm having an issue with TLS in python-ldap. I can get a few basic use > cases working, but it appears that it's not possible to change some TLS > context parameters at runtime after they have initially been set. Here's a > test case i've reproduced: ldap.set_option(ldap.OPT_X_TLS_NEWCTX, 0) has to be the last TLS option set. Yes, it's strange but that's the way the OpenLDAP API works. CIao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From mehaase at gmail.com Tue Apr 29 20:55:07 2014 From: mehaase at gmail.com (Mark E. Haase) Date: Tue, 29 Apr 2014 14:55:07 -0400 Subject: [python-ldap] Issue with TLS contexts... In-Reply-To: <535F48E6.3020600@stroeder.com> References: <535F48E6.3020600@stroeder.com> Message-ID: Michael, thanks for the pointer! It's working now. Really appreciate the help. I was beginning to pull my hair out. On Tue, Apr 29, 2014 at 2:38 AM, Michael Str?der wrote: > Mark E. Haase wrote: > > I'm having an issue with TLS in python-ldap. I can get a few basic use > > cases working, but it appears that it's not possible to change some TLS > > context parameters at runtime after they have initially been set. Here's > a > > test case i've reproduced: > > ldap.set_option(ldap.OPT_X_TLS_NEWCTX, 0) has to be the last TLS option > set. > > Yes, it's strange but that's the way the OpenLDAP API works. > > CIao, Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri May 2 20:32:29 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 02 May 2014 20:32:29 +0200 Subject: [python-ldap] SyncRepl demo improvements Message-ID: <5363E4BD.7080606@redhat.com> Hello! Attached patches improve various aspects of SyncRepl demo. Maybe it would be valuable to provide change detection logic from this demo as part of the python-ldap library. IMHO the code is almost done. It would only require only minor changes. Main thing is storage (__data) separation from SyncReplConsumer class. Second thing could be optional limiting amount of data stored in the __data to UUID and DN or something like that. What do you think? -- Petr Spacek @ Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Demo-pyasn1-syncrepl.py-add-command-line-example.patch Type: text/x-patch Size: 1210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Demo-pyasn1-syncrepl.py-fix-mysterious-database-corr.patch Type: text/x-patch Size: 1120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Demo-pyasn1-syncrepl.py-separate-object-data-to-__da.patch Type: text/x-patch Size: 3675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Demo-pyasn1-syncrepl.py-respect-attribute-list-in-LD.patch Type: text/x-patch Size: 778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Demo-pyasn1-syncrepl.py-fix-application_sync.patch Type: text/x-patch Size: 1079 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Demo-pyasn1-syncrepl.py-add-application_add-and-_del.patch Type: text/x-patch Size: 2328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Demo-pyasn1-syncrepl.py-separate-SyncReplConsumer-cl.patch Type: text/x-patch Size: 5368 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Demo-pyasn1-syncrepl.py-add-detailed-debug-messages.patch Type: text/x-patch Size: 5803 bytes Desc: not available URL: From lumi.moruz at gmail.com Wed May 7 09:54:44 2014 From: lumi.moruz at gmail.com (Luminita Moruz) Date: Wed, 7 May 2014 09:54:44 +0200 Subject: [python-ldap] Problems with using SASL and unicode Message-ID: Hi, I am trying to use python-ldap with SASL. but I am not able to get SASL working when the username or password contain special characters. The code is given below. Any help with this would be greatly appreciated. # -*- coding: utf-8 -*- import ldap import ldap.sasl def my_function(username, password): try: ldap_connection = ldap.initialize(LDAP_SERVER) ldap_connection.set_option(ldap.OPT_REFERRALS, 0) ldap_connection.protocol_version = 3 auth_tokens = ldap.sasl.digest_md5(username, password) ldap_connection.sasl_interactive_bind_s("", auth_tokens) except ldap.INVALID_CREDENTIALS, e: print e def main(): u = u"user" p = u"pass" my_function(u.encode("utf-8"), p.encode("utf-8")) This works just fine if the username and password do not contain any special characters, but gives {'info': '8009030C: LdapErr: DSID-0C0904F8, comment: AcceptSecurityContext error, data 52e, v23f0', 'desc': 'Invalid credentials'} otherwise. Thanks, Luminita -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed May 7 18:32:31 2014 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 May 2014 18:32:31 +0200 Subject: [python-ldap] Problems with using SASL and unicode In-Reply-To: References: Message-ID: <536A601F.3070404@stroeder.com> Luminita Moruz wrote: > I am trying to use python-ldap with SASL. but I am not able to get SASL > working when the username or password contain special characters. > def main(): > [..] > u = u"user" > p = u"pass" > my_function(u.encode("utf-8"), p.encode("utf-8")) > [..] > {'info': '8009030C: LdapErr: DSID-0C0904F8, comment: AcceptSecurityContext > error, data 52e, v23f0', 'desc': 'Invalid credentials'} otherwise. This is buggy MS AD. Use .encode('iso-8859-1') with this crap (although the SASL handshake observed with Wireshark also mentions UTF-8). Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From lumi.moruz at gmail.com Thu May 8 07:59:58 2014 From: lumi.moruz at gmail.com (Luminita Moruz) Date: Thu, 8 May 2014 07:59:58 +0200 Subject: [python-ldap] Problems with using SASL and unicode In-Reply-To: <536A601F.3070404@stroeder.com> References: <536A601F.3070404@stroeder.com> Message-ID: Hi Michael, Thanks for the fast reply, it worked like a charm. Luminita On Wed, May 7, 2014 at 6:32 PM, Michael Str?der wrote: > Luminita Moruz wrote: > > I am trying to use python-ldap with SASL. but I am not able to get SASL > > working when the username or password contain special characters. > > def main(): > > [..] > > u = u"user" > > p = u"pass" > > my_function(u.encode("utf-8"), p.encode("utf-8")) > > [..] > > {'info': '8009030C: LdapErr: DSID-0C0904F8, comment: > AcceptSecurityContext > > error, data 52e, v23f0', 'desc': 'Invalid credentials'} otherwise. > > This is buggy MS AD. Use .encode('iso-8859-1') with this crap > (although the SASL handshake observed with Wireshark also mentions UTF-8). > > Ciao, Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.meany at gmail.com Sun May 11 03:51:44 2014 From: robert.meany at gmail.com (Robert Meany) Date: Sat, 10 May 2014 21:51:44 -0400 Subject: [python-ldap] Modifying AD nTSecurityDescriptor Message-ID: Hey, A couple weeks ago I posted a question about querying the nTSecurityDescriptor to update the 'user cannot change password' flag for active directory accounts. The general consensus was that you needed to use ADSI or win32com objects to work with the security descriptor... Just wanted to let folks know, in case anyone else in the future is looking for this functionality in pure python, that I wrote some code to manipulate the nTSecurityDescriptor attribute directly through LDAP. I posted an article, along with source code on my blog at http://www.robertmeany.com ... Feel free to use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstanek at dstanek.com Tue May 27 18:26:58 2014 From: dstanek at dstanek.com (David Stanek) Date: Tue, 27 May 2014 12:26:58 -0400 Subject: [python-ldap] Python3 Status Question Message-ID: Hello All, I'm in the process of getting the OpenStack Keystone project to work on Python 3. Part of this work is to get all of our dependencies to also work against Python 3. It looks like there have been several attempts for python-ldap, with the most promising being the one recently announced[1] on this list. This patchset is working so far, but I have quite a bit more testing to do including more changes to Keystone so that I can actually run full tests. What is the process for getting these patches accepted? Thanks! 1. https://mail.python.org/pipermail/python-ldap/2014q1/003348.html -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From raphael.barrois at m4x.org Tue May 27 23:35:37 2014 From: raphael.barrois at m4x.org (=?UTF-8?B?UmFwaGHDq2w=?= Barrois) Date: Tue, 27 May 2014 23:35:37 +0200 Subject: [python-ldap] Python3 Status Question In-Reply-To: References: Message-ID: <20140527233537.61c0e498@corvis> On Tue, 27 May 2014 12:26:58 -0400 David Stanek wrote: > Hello All, > > I'm in the process of getting the OpenStack Keystone project to work > on Python 3. Part of this work is to get all of our dependencies to > also work against Python 3. It looks like there have been several > attempts for python-ldap, with the most promising being the one > recently announced[1] on this list. > > This patchset is working so far, but I have quite a bit more testing > to do including more changes to Keystone so that I can actually run > full tests. What is the process for getting these patches accepted? > > Thanks! > > 1. https://mail.python.org/pipermail/python-ldap/2014q1/003348.html > Hi David, If you've got additional changes to make to my Python3-compatible version, feel free to push them on this mailing list or as issues on the github repository at https://github.com/rbarrois/python-ldap. Regarding the inclusion of Python3-related patches into python-ldap, I'd love to get the opinion of Michael Str?der on that topic. From my point of view, there are now three options: - Improve and merge these changes into the main python-ldap tree - Decide that switching to Python3 should be an occasion for significant API redesign, and release that version under a new name - Refuse to support Python3 in python-ldap, in which case I'll work on distributing my fork under another name. Michael, what's your opinion on this? -- Rapha?l From raphael.barrois at polytechnique.org Tue May 27 23:53:03 2014 From: raphael.barrois at polytechnique.org (=?UTF-8?B?UmFwaGHDq2w=?= Barrois) Date: Tue, 27 May 2014 23:53:03 +0200 Subject: [python-ldap] Python3 Status Question In-Reply-To: References: <20140527233537.61c0e498@corvis> Message-ID: <20140527235303.17e780c7@corvis> On Tue, 27 May 2014 17:41:24 -0400 David Stanek wrote: > On Tue, May 27, 2014 at 5:35 PM, Rapha?l Barrois > wrote: > > > On Tue, 27 May 2014 12:26:58 -0400 > > David Stanek wrote: > > > > > Hello All, > > > > > > I'm in the process of getting the OpenStack Keystone project to > > > work on Python 3. Part of this work is to get all of our > > > dependencies to also work against Python 3. It looks like there > > > have been several attempts for python-ldap, with the most > > > promising being the one recently announced[1] on this list. > > > > > > This patchset is working so far, but I have quite a bit more > > > testing to do including more changes to Keystone so that I can > > > actually run full tests. What is the process for getting these > > > patches accepted? > > > > > > Thanks! > > > > > > 1. > > > https://mail.python.org/pipermail/python-ldap/2014q1/003348.html > > > > > > > > > - Decide that switching to Python3 should be an occasion for > > significant API redesign, and release that version under a new > > name > > > I'm curious about this option. Is a API redesign on the table because > of Py3 changes (str->bytes, etc.) or is it just an opportunity to > make a change? > > > This seemed to be an option when I scrubbed the archives before starting my Py3 version, see for instance https://mail.python.org/pipermail/python-ldap/2012q2/003115.html. Regarding my Py3 fork, the goal is to provide a consistent API for both Py2 and Py3, where code using python-ldap can be used the same in both versions. This is not always easy, especially in places where objects are returned as bytes where the RFC states they are actually UTF-8 encoded text ; in such situations, we'll have to decide whether we go for backwards-compatibility or for future-proof design. -- Rapha?l From dstanek at dstanek.com Tue May 27 23:41:24 2014 From: dstanek at dstanek.com (David Stanek) Date: Tue, 27 May 2014 17:41:24 -0400 Subject: [python-ldap] Python3 Status Question In-Reply-To: <20140527233537.61c0e498@corvis> References: <20140527233537.61c0e498@corvis> Message-ID: On Tue, May 27, 2014 at 5:35 PM, Rapha?l Barrois wrote: > On Tue, 27 May 2014 12:26:58 -0400 > David Stanek wrote: > > > Hello All, > > > > I'm in the process of getting the OpenStack Keystone project to work > > on Python 3. Part of this work is to get all of our dependencies to > > also work against Python 3. It looks like there have been several > > attempts for python-ldap, with the most promising being the one > > recently announced[1] on this list. > > > > This patchset is working so far, but I have quite a bit more testing > > to do including more changes to Keystone so that I can actually run > > full tests. What is the process for getting these patches accepted? > > > > Thanks! > > > > 1. https://mail.python.org/pipermail/python-ldap/2014q1/003348.html > > > > - Decide that switching to Python3 should be an occasion for > significant API redesign, and release that version under a new name I'm curious about this option. Is a API redesign on the table because of Py3 changes (str->bytes, etc.) or is it just an opportunity to make a change? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ck-lists at cksoft.de Wed May 28 10:00:13 2014 From: ck-lists at cksoft.de (Christian Kratzer) Date: Wed, 28 May 2014 10:00:13 +0200 (CEST) Subject: [python-ldap] Specificy multiple ldap servers for ldap.initialize Message-ID: Hi, what would be the most pythonic and elegant way to specify multiple ldap servers to connect to for HA purposes. I run two ldap servers in two VM on two different hosts and have several scripts connecting to them. I would like to make connection transparent when the primary server fails. I currently have following leftover from my previous experiments: ldap_url = [ 'ldap://ldap1.cksoft.de/', 'ldap://ldap2.cksoft.de/' ] l = ldap.initialize( ldap_url[0] ) Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From michael at stroeder.com Wed May 28 10:17:36 2014 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 28 May 2014 10:17:36 +0200 Subject: [python-ldap] Specificy multiple ldap servers for ldap.initialize In-Reply-To: References: Message-ID: <53859BA0.1030004@stroeder.com> Christian Kratzer wrote: > what would be the most pythonic and elegant way to specify multiple ldap > servers to connect to for HA purposes. > > I run two ldap servers in two VM on two different hosts and have several > scripts connecting to them. I would like to make connection transparent when > the primary server fails. > > I currently have following leftover from my previous experiments: > > ldap_url = [ 'ldap://ldap1.cksoft.de/', 'ldap://ldap2.cksoft.de/' ] > l = ldap.initialize( ldap_url[0] ) ldap.initialize() simply passes argument uri to LDAPObject.__init__() which in turn passes it directly to the OpenLDAP API. The OpenLDAP API expects a string with all possible URIs separated with a space if you want libldap to do the fail-over. But letting libldap do the reconnect is pretty bad because your Python code will never get noticed about to which server your application is actually connected to. Therefore I'd recommend to write your own thin wrapper around either ldap.initialize() or LDAPObject.__init__(). This may depend on what your favourite LDAPObject flavor is. Most times I'm using ReconnectLDAPObject. Note that fail-over also comes in different flavors depending on whether DNS round robin or a real load-balancer is part of the game. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Wed May 28 15:51:06 2014 From: jdennis at redhat.com (John Dennis) Date: Wed, 28 May 2014 09:51:06 -0400 Subject: [python-ldap] Python3 Status Question In-Reply-To: <20140527235303.17e780c7@corvis> References: <20140527233537.61c0e498@corvis> <20140527235303.17e780c7@corvis> Message-ID: <5385E9CA.8050902@redhat.com> On 05/27/2014 05:53 PM, Rapha?l Barrois wrote: > On Tue, 27 May 2014 17:41:24 -0400 > David Stanek wrote: > >> On Tue, May 27, 2014 at 5:35 PM, Rapha?l Barrois >> wrote: >> >>> On Tue, 27 May 2014 12:26:58 -0400 >>> David Stanek wrote: >>> >>>> Hello All, >>>> >>>> I'm in the process of getting the OpenStack Keystone project to >>>> work on Python 3. Part of this work is to get all of our >>>> dependencies to also work against Python 3. It looks like there >>>> have been several attempts for python-ldap, with the most >>>> promising being the one recently announced[1] on this list. >>>> >>>> This patchset is working so far, but I have quite a bit more >>>> testing to do including more changes to Keystone so that I can >>>> actually run full tests. What is the process for getting these >>>> patches accepted? >>>> >>>> Thanks! >>>> >>>> 1. >>>> https://mail.python.org/pipermail/python-ldap/2014q1/003348.html >>>> >>> >> >> >>> - Decide that switching to Python3 should be an occasion for >>> significant API redesign, and release that version under a new >>> name >> >> >> I'm curious about this option. Is a API redesign on the table because >> of Py3 changes (str->bytes, etc.) or is it just an opportunity to >> make a change? >> >> >> > > This seemed to be an option when I scrubbed the archives before > starting my Py3 version, see for instance > https://mail.python.org/pipermail/python-ldap/2012q2/003115.html. > > Regarding my Py3 fork, the goal is to provide a consistent API for both > Py2 and Py3, where code using python-ldap can be used the same in both > versions. > This is not always easy, especially in places where objects > are returned as bytes where the RFC states they are actually UTF-8 > encoded text ; in such situations, we'll have to decide whether we go > for backwards-compatibility or for future-proof design. The fact the python-ldap API cannot accept unicode (with non-ASCII chars) input and only returns UTF-8 encoded data is one of the most difficult aspects of using python-ldap. In most cases it requires writing a new API for a Python applicaton whose sole responsibility is to act as an encode/decode wrapper insulating the application code from python-ldap. I believe the utf-8 encode/decode should be the responsibility of the ldap binding (i.e. python-ldap) instead of the application. This would be ideal because the application could just use unicode for it's text strings (as it should) and be able to simply call python-ldap without concern. However, we do have history to consider. Here is my suggestion. 1) Incoming parameters are checked to see if they are bytes or unicode. If it's bytes then assume it's already utf-8 encoded. Otherwise encode the unicode to utf-8. This is relatively easy to code in CPython. 2) Introduce a flag to control utf-8 decoding for output values. In python2 the flag defaults to False to be consistent with existing behavior. In python3 it defaults to True (so applications can just use strings in a sane manner consistent with Python3 strings). This way legacy code will continue to run correctly, python2 code could avoid an encode/decode wrapper if chose to and python3 code could just use strings without concerns but would have the option fallback to the previous behavior. It's the best of both worlds. Having written a fair amount of code which uses python-ldap I'd love to get out of the encode/decode game, it's the source of a lot of problems (usually not discovered until the code is in the field when non-English users start supplying user values and then the code will need a fair amount of refactoring to start using encode/decode wrappers). P.S.: One also has to be careful to distinguish between the portions of python-ldap which is written in pure Python vs. those which are written in CPython. Currently the pure Python code behaves differently, you can pass unicode and usually the right thing happens because the interpreter recognizes it as unicode instead of being subjected to the default encoding applied in PyArg_ParseTuple*() in the CPython binding (when the parameter is marked as a string). -- John From flo at chaoflow.net Thu Jun 19 15:43:30 2014 From: flo at chaoflow.net (Florian Friesdorf) Date: Thu, 19 Jun 2014 15:43:30 +0200 Subject: [python-ldap] How to search the python-ldap list? Message-ID: <87lhst10cd.fsf@chaoflow.net> Hi, I might miss the obivious: Is there a publicly accessible way to search the python-ldap mailing list? best regards Florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From jcasale at activenetwerx.com Thu Jun 19 16:46:44 2014 From: jcasale at activenetwerx.com (Joseph L. Casale) Date: Thu, 19 Jun 2014 14:46:44 +0000 Subject: [python-ldap] How to search the python-ldap list? In-Reply-To: <87lhst10cd.fsf@chaoflow.net> References: <87lhst10cd.fsf@chaoflow.net> Message-ID: <8fd71e3137844227998b659f6504c73e@exch.activenetwerx.com> > I might miss the obivious: Is there a publicly accessible way to search > the python-ldap mailing list? Like all python.org hosted lists: https://mail.python.org/mailman/listinfo/python3-ldap From flo at chaoflow.net Thu Jun 19 16:56:50 2014 From: flo at chaoflow.net (Florian Friesdorf) Date: Thu, 19 Jun 2014 16:56:50 +0200 Subject: [python-ldap] Licensing In-Reply-To: <4FB675E5.1040402@stroeder.com> References: <3F577A73-A6DE-4DA7-888A-4C964DDFF309@allegro.pl> <4FB675E5.1040402@stroeder.com> Message-ID: <87egyl0wy5.fsf@chaoflow.net> Dear Michael, Michael Str?der writes: > Radomir Dopieralski wrote: >> (..) >> Without a concrete text of the license for our lawyers to review we are >> blocked from releasing our project to the public, as it is perceived as >> threat to the company. Would it be possible to include a full text of the >> license in the LICENSE file, or an unambiguous reference to a specific >> license? That would help us a lot. > > Mentioning a Python style license was my fault for two reasons: > > 1. It is an obstacle to incorporate python-ldap into Python's standard lib. > > 2. It's not precise enough as you already said. > > Mainly the term "Python style" was used to express that you should be able to > do whatever you're allowed to do with Python. > > The two authors (David and me) writing most of the code could agree on a quite > liberal open source license. Do you have a specific license in mind? http://www.gnu.org/licenses/license-list.html#Python The current python license is non-copyleft and compatible with GPL. > But since we did not insist on written statements > to agree upon a license for the few contributions made by others we would have > to ask all contributors. Most of them are not subscribed to the list anymore I > guess. > > Frankly I'm not sure what to do to clarify this unfortunate situation. I suggest and am willing to help: - you (and David) as the main authors decide on a desired license - we figure out the authors email address / other means of contacting them - we contact the authors and ask for their permission to relicense From the logs: | author | number of commits | when | |-------------+-------------------+-----------| | aschauer | 3 | 2002 | | deepak_giri | 4 | 2005 | | fog | 9 | 2000 | | jajcus | 18 | 2001 | | jlt63 | 1 | 2001 | | kchuguev | 1 | 2001 | | leonard | 138 | 2000-2009 | | stroeder | 1251 | ongoing | | uid32935 | 2 | 2001 | Do you have names and email addresses of the authors? kchuguev's I found while browsing the commit logs. best regards Florian PS: I removed Radomir from the recipients as his email address is no longer active. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From flo at chaoflow.net Thu Jun 19 17:00:49 2014 From: flo at chaoflow.net (Florian Friesdorf) Date: Thu, 19 Jun 2014 17:00:49 +0200 Subject: [python-ldap] How to search the python-ldap list? In-Reply-To: <8fd71e3137844227998b659f6504c73e@exch.activenetwerx.com> References: <87lhst10cd.fsf@chaoflow.net> <8fd71e3137844227998b659f6504c73e@exch.activenetwerx.com> Message-ID: <87a9990wri.fsf@chaoflow.net> "Joseph L. Casale" writes: >> I might miss the obivious: Is there a publicly accessible way to search >> the python-ldap mailing list? > > Like all python.org hosted lists: > > https://mail.python.org/mailman/listinfo/python3-ldap I assume you meant https://mail.python.org/mailman/listinfo/python-ldap (not the one for python3-ldap), which is also listed at http://python-ldap.org/. However, I can only see a way to browse the archives like that, in contrast to actually search them. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From jcasale at activenetwerx.com Thu Jun 19 17:16:33 2014 From: jcasale at activenetwerx.com (Joseph L. Casale) Date: Thu, 19 Jun 2014 15:16:33 +0000 Subject: [python-ldap] How to search the python-ldap list? In-Reply-To: <87a9990wri.fsf@chaoflow.net> References: <87lhst10cd.fsf@chaoflow.net> <8fd71e3137844227998b659f6504c73e@exch.activenetwerx.com>, <87a9990wri.fsf@chaoflow.net> Message-ID: > I assume you meant https://mail.python.org/mailman/listinfo/python-ldap > (not the one for python3-ldap), which is also listed at > http://python-ldap.org/. > > However, I can only see a way to browse the archives like that, in > contrast to actually search them. Oops, my bad. Try gmane: http://blog.gmane.org/gmane.comp.python.ldap There are a myriad of mailing list archive sites that do this. jlc From torriem at gmail.com Fri Jun 20 01:06:08 2014 From: torriem at gmail.com (Michael Torrie) Date: Thu, 19 Jun 2014 17:06:08 -0600 Subject: [python-ldap] How to search the python-ldap list? In-Reply-To: <87a9990wri.fsf@chaoflow.net> References: <87lhst10cd.fsf@chaoflow.net> <8fd71e3137844227998b659f6504c73e@exch.activenetwerx.com> <87a9990wri.fsf@chaoflow.net> Message-ID: <53A36CE0.1040005@gmail.com> On 06/19/2014 09:00 AM, Florian Friesdorf wrote: > > "Joseph L. Casale" writes: >>> I might miss the obivious: Is there a publicly accessible way to search >>> the python-ldap mailing list? >> >> Like all python.org hosted lists: >> >> https://mail.python.org/mailman/listinfo/python3-ldap > > I assume you meant https://mail.python.org/mailman/listinfo/python-ldap > (not the one for python3-ldap), which is also listed at > http://python-ldap.org/. > > However, I can only see a way to browse the archives like that, in > contrast to actually search them. I typically download the gzipped archive and grep it myself. It's trivial to write a little script to download all the archives going back 14 years. From pspacek at redhat.com Fri Jun 20 09:38:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 Jun 2014 09:38:38 +0200 Subject: [python-ldap] Licensing In-Reply-To: <87egyl0wy5.fsf@chaoflow.net> References: <3F577A73-A6DE-4DA7-888A-4C964DDFF309@allegro.pl> <4FB675E5.1040402@stroeder.com> <87egyl0wy5.fsf@chaoflow.net> Message-ID: <53A3E4FE.6040209@redhat.com> On 19.6.2014 16:56, Florian Friesdorf wrote: > > Dear Michael, > > Michael Str?der writes: >> Radomir Dopieralski wrote: >>> (..) >>> Without a concrete text of the license for our lawyers to review we are >>> blocked from releasing our project to the public, as it is perceived as >>> threat to the company. Would it be possible to include a full text of the >>> license in the LICENSE file, or an unambiguous reference to a specific >>> license? That would help us a lot. >> >> Mentioning a Python style license was my fault for two reasons: >> >> 1. It is an obstacle to incorporate python-ldap into Python's standard lib. >> >> 2. It's not precise enough as you already said. >> >> Mainly the term "Python style" was used to express that you should be able to >> do whatever you're allowed to do with Python. >> >> The two authors (David and me) writing most of the code could agree on a quite >> liberal open source license. > > Do you have a specific license in mind? > > http://www.gnu.org/licenses/license-list.html#Python > > The current python license is non-copyleft and compatible with GPL. > >> But since we did not insist on written statements >> to agree upon a license for the few contributions made by others we would have >> to ask all contributors. Most of them are not subscribed to the list anymore I >> guess. >> >> Frankly I'm not sure what to do to clarify this unfortunate situation. > > I suggest and am willing to help: > > - you (and David) as the main authors decide on a desired license > > - we figure out the authors email address / other means of contacting > them > > - we contact the authors and ask for their permission to relicense > > From the logs: > > | author | number of commits | when | > |-------------+-------------------+-----------| > | aschauer | 3 | 2002 | > | deepak_giri | 4 | 2005 | > | fog | 9 | 2000 | > | jajcus | 18 | 2001 | > | jlt63 | 1 | 2001 | > | kchuguev | 1 | 2001 | > | leonard | 138 | 2000-2009 | > | stroeder | 1251 | ongoing | > | uid32935 | 2 | 2001 | I don't want to thwart re-licensing effort but please keep in mind that there could be commits from different authors (e.g. me :-) buried under other account names (stroeder in my case). I have no idea how common it is, maybe it is exceptional mistake. Petr^2 Spacek > Do you have names and email addresses of the authors? > > kchuguev's I found while browsing the commit logs. > > best regards > Florian > > > PS: I removed Radomir from the recipients as his email address is no > longer active. From flo at chaoflow.net Sat Jun 21 10:24:56 2014 From: flo at chaoflow.net (Florian Friesdorf) Date: Sat, 21 Jun 2014 10:24:56 +0200 Subject: [python-ldap] How to search the python-ldap list? In-Reply-To: <53A36CE0.1040005@gmail.com> References: <87lhst10cd.fsf@chaoflow.net> <8fd71e3137844227998b659f6504c73e@exch.activenetwerx.com> <87a9990wri.fsf@chaoflow.net> <53A36CE0.1040005@gmail.com> Message-ID: <87simyzn3b.fsf@chaoflow.net> Michael Torrie writes: > On 06/19/2014 09:00 AM, Florian Friesdorf wrote: >> >> "Joseph L. Casale" writes: >>>> I might miss the obivious: Is there a publicly accessible way to search >>>> the python-ldap mailing list? >>> >>> Like all python.org hosted lists: >>> >>> https://mail.python.org/mailman/listinfo/python3-ldap >> >> I assume you meant https://mail.python.org/mailman/listinfo/python-ldap >> (not the one for python3-ldap), which is also listed at >> http://python-ldap.org/. >> >> However, I can only see a way to browse the archives like that, in >> contrast to actually search them. > > I typically download the gzipped archive and grep it myself. It's > trivial to write a little script to download all the archives going back > 14 years. Thx Michael and Joseph! I failed to find python-ldap on gmane, though I was searching for it, and I had the idea of writing a script. For me it would have been helpful to have a link to gmane and/or a copy-paste script right next to the link to the archives. While I found a way to search, It might be useful to put such info there. best regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From michael at stroeder.com Sat Jun 21 12:45:15 2014 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 21 Jun 2014 12:45:15 +0200 Subject: [python-ldap] How to search the python-ldap list? In-Reply-To: <87simyzn3b.fsf@chaoflow.net> References: <87lhst10cd.fsf@chaoflow.net> <8fd71e3137844227998b659f6504c73e@exch.activenetwerx.com> <87a9990wri.fsf@chaoflow.net> <53A36CE0.1040005@gmail.com> <87simyzn3b.fsf@chaoflow.net> Message-ID: <53A5623B.2030900@stroeder.com> Florian Friesdorf wrote: > While I found a way to search, It might be useful to put such info > there. Well, using Google shouldn't be that hard. Example: https://www.google.com/search?q=site:mail.python.org+python-ldap+Florian+Friesdorf Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From flo at chaoflow.net Sat Jun 21 21:31:58 2014 From: flo at chaoflow.net (Florian Friesdorf) Date: Sat, 21 Jun 2014 21:31:58 +0200 Subject: [python-ldap] How to search the python-ldap list? In-Reply-To: <53A5623B.2030900@stroeder.com> References: <87lhst10cd.fsf@chaoflow.net> <8fd71e3137844227998b659f6504c73e@exch.activenetwerx.com> <87a9990wri.fsf@chaoflow.net> <53A36CE0.1040005@gmail.com> <87simyzn3b.fsf@chaoflow.net> <53A5623B.2030900@stroeder.com> Message-ID: <87fviyys7l.fsf@chaoflow.net> Michael Str?der writes: > Florian Friesdorf wrote: >> While I found a way to search, It might be useful to put such info >> there. > > Well, using Google shouldn't be that hard. > > Example: > > https://www.google.com/search?q=site:mail.python.org+python-ldap+Florian+Friesdorf I tried: https://www.google.de/search?q=gmane+python-ldap+Florian+Friesdorf Thx for sharing your clearly better way... -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: