From manuvkumar at gmail.com Mon Oct 2 14:22:58 2017 From: manuvkumar at gmail.com (manu kumar) Date: Mon, 2 Oct 2017 23:52:58 +0530 Subject: [python-ldap] Does pyldap support VLV and SSS control Message-ID: Hi, Please let me know does pyldap support SSS and VLV ldap contorls. Thanks, Manu -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Oct 2 14:54:44 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 2 Oct 2017 20:54:44 +0200 Subject: [python-ldap] Does pyldap support VLV and SSS control In-Reply-To: References: Message-ID: manu kumar wrote: > Please let me know does pyldap support SSS and VLV ldap contorls. Yes. See (not yet documented) modules ldap.controls.sss and ldap.controls.vlv. See also in source distribution: Demo/pyasn1/sss_highest_number.py Ciao, Michael. P.S.: Please subscribe to the python-ldap mailing list. So I don't have to improve your postings. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Oct 2 15:02:01 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 2 Oct 2017 21:02:01 +0200 Subject: [python-ldap] Does pyldap support VLV and SSS control In-Reply-To: References: Message-ID: <80f0f790-683a-feb4-c457-65781a5e566f@stroeder.com> Michael Str?der wrote: > P.S.: Please subscribe to the python-ldap mailing list. So I don't > have to improve your postings. ^^^^^^^ Should have said "approve" off course. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From best at univention.de Tue Oct 10 07:11:15 2017 From: best at univention.de (Florian Best) Date: Tue, 10 Oct 2017 13:11:15 +0200 Subject: [python-ldap] Function signature wrong documented Message-ID: <20b5e5b2-91fe-7280-eb5a-96522d0856a6@univention.de> Hello, The function documentation of |LDAPObject.||modify_ext_s|is documented wrong: https://www.python-ldap.org/doc/html/ldap.html It says it returns None while it actually returns a 4-tuple (resp_type, resp_data, resp_msgid, resp_ctrls). Best regards Florian -- Florian Best Open Source Software Engineer Univention GmbH be open Mary-Somerville-Str.1 28359 Bremen Tel.: +49 421 22232-0 Fax : +49 421 22232-99 best at univention.de http://www.univention.de Gesch?ftsf?hrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aigars.grins at sentor.se Fri Oct 27 03:31:02 2017 From: aigars.grins at sentor.se (Aigars Grins) Date: Fri, 27 Oct 2017 09:31:02 +0200 Subject: [python-ldap] Strange network problems? In-Reply-To: <3af81653-5b46-1077-0389-368a0338b126@stroeder.com> References: <1775e9e5-25c7-330b-8b8c-dc7710e75d38@sentor.se> <5f019174-ea64-309f-cdbf-a0884a5b2979@stroeder.com> <80f8109d-e5ce-9407-8a02-897b0f18f71e@sentor.se> <3af81653-5b46-1077-0389-368a0338b126@stroeder.com> Message-ID: Hi, On 2017-09-20 10:49, Michael Str?der wrote: > Aigars Grins wrote: >> With regards to "errors in the randomness device", the internet tells >> me that some other projects [1] switched over to bind against >> OpenSSL instead. Would it be possible to do that for python-ldap as >> well? Some kind of compiler flag I could set? >> >> [1] > > The Debian developers, with their infinite wisdom and anti-OpenSSL > licensing paranoia, decided to link libldap against GnuTLS. This causes > nothing than grief but they are pretty much ignorant to change that. > > If you want to change that you have to compile the whole stack [1] > yourself and take care of not mixing dynamic linking with OS-installed > libldap: > > [1] https://www.python-ldap.org/doc/html/installing.html#prerequisites > > Maybe you could try to build a statically linked python-ldap with all > the issues with that solution (updates etc.). I've done just that. That is, built a python-ldap that's statically linked with OpenSSL. I'm happy to report that my logs no longer contain any "errors in the randomness device". -- Aigars From prabhav.parashar at gmail.com Wed Nov 1 12:16:23 2017 From: prabhav.parashar at gmail.com (Prabhav Parashar) Date: Wed, 1 Nov 2017 12:16:23 -0400 Subject: [python-ldap] Couple of problems in pip install Message-ID: Hi it seems that in the setup.py file from the PyPi repo there are a couple of typos resulting in failed installation, the most obvious of which is a missing parenthesis -- Prabhav -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Nov 1 15:28:09 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 1 Nov 2017 20:28:09 +0100 Subject: [python-ldap] Couple of problems in pip install In-Reply-To: References: Message-ID: Prabhav Parashar wrote: > Hi it seems that in the setup.py file from the PyPi repo there are a > couple of typos resulting in failed installation, the most obvious of > which is a missing parenthesis Works for me (see below). Please elaborate on what *exactly* you're doing. Ciao, Michael. P.S.: You should subscribe to the python-ldap mailing list. Otherwise you might miss responses. --------------------------- snip --------------------------- $ virtualenv-2.7 pyldaptest New python executable in /tmp/pyldaptest/bin/python2 Also creating executable in /tmp/pyldaptest/bin/python Installing setuptools, pip, wheel...done. $ pyldaptest/bin/python2 python2 python2.7 michael at nb2:~/tmp> pyldaptest/bin/pip2 pip2 pip2.7 michael at nb2:~/tmp> pyldaptest/bin/pip2.7 install python-ldap Collecting python-ldap Downloading python-ldap-2.4.45.tar.gz (296kB) 100% |????????????????????????????????| 296kB 1.7MB/s Requirement already satisfied: setuptools in ./pyldaptest/lib/python2.7/site-packages (from python-ldap) Building wheels for collected packages: python-ldap Running setup.py bdist_wheel for python-ldap ... done Stored in directory: /home/michael/.cache/pip/wheels/3e/1a/62/ea4a87892c2f95703f0822d253d8ab5efe810b13d0033db89a Successfully built python-ldap Installing collected packages: python-ldap Successfully installed python-ldap-2.4.45 $ pyldaptest/bin/python2.7 -c "import ldap ; print ldap.__version__" 2.4.45 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From christian at python.org Tue Nov 7 07:34:39 2017 From: christian at python.org (Christian Heimes) Date: Tue, 7 Nov 2017 13:34:39 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 Message-ID: Hi Michael, syncrepl does no longer work with pyasn1 >= 0.3. pyasn1 changed its API a bit. Ilya, the author and maintainer of pyasn1, has provided a fix for Python 3 port of python-ldap. I have attached his original patch and a backport to python-ldap. Patch source: https://github.com/pyldap/pyldap/pull/126 Regards, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: accommodate-changed-pyasn1-behaviour-cvs.patch Type: text/x-patch Size: 6513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: accommodate-changed-pyasn1-behaviour-git.patch Type: text/x-patch Size: 7192 bytes Desc: not available URL: From michael at stroeder.com Tue Nov 7 07:53:19 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 7 Nov 2017 13:53:19 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: References: Message-ID: Christian Heimes wrote: > syncrepl does no longer work with pyasn1 >= 0.3. pyasn1 changed its API > a bit. Ilya, the author and maintainer of pyasn1, has provided a fix for > Python 3 port of python-ldap. I have attached his original patch and a > backport to python-ldap. > > Patch source: https://github.com/pyldap/pyldap/pull/126 Many thanks for your contribution. Is this code still compatible with pyasn1 < 0.3? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From christian at python.org Tue Nov 7 07:55:16 2017 From: christian at python.org (Christian Heimes) Date: Tue, 7 Nov 2017 13:55:16 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: References: Message-ID: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> On 2017-11-07 13:53, Michael Str?der wrote: > Christian Heimes wrote: >> syncrepl does no longer work with pyasn1 >= 0.3. pyasn1 changed its API >> a bit. Ilya, the author and maintainer of pyasn1, has provided a fix for >> Python 3 port of python-ldap. I have attached his original patch and a >> backport to python-ldap. >> >> Patch source: https://github.com/pyldap/pyldap/pull/126 > > Many thanks for your contribution. > > Is this code still compatible with pyasn1 < 0.3? According to Ilya, the code is compatible with any reasonable recent version of pyasn1 0.2, too. All checks first do 'value is None' for pyasn1, then 'not value.hasValue()'. Christian From christian at python.org Tue Nov 7 08:03:51 2017 From: christian at python.org (Christian Heimes) Date: Tue, 7 Nov 2017 14:03:51 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> Message-ID: <64719914-75c3-4eac-dc4c-d65bd69b1019@python.org> On 2017-11-07 13:58, Ilya Etingof wrote: > > Exactly! This patch should not compromise current compatibility > situation, but only extend it to current pyasn1 API. > > Thank you Christian for porting the patch! You are welcome! However the patch is not correct. You'll missed a spot. I'll provide a new patch shortly. Christian From christian at python.org Tue Nov 7 08:48:22 2017 From: christian at python.org (Christian Heimes) Date: Tue, 7 Nov 2017 14:48:22 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> Message-ID: <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> On 2017-11-07 13:58, Ilya Etingof wrote: > > Exactly! This patch should not compromise current compatibility > situation, but only extend it to current pyasn1 API. > > Thank you Christian for porting the patch! Here is a new patch. I tested it with FreeIPA's ipa-dnskeysyncd. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: accommodate-changed-pyasn1-behaviour.patch Type: text/x-patch Size: 7523 bytes Desc: not available URL: From michael at stroeder.com Tue Nov 7 16:30:16 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 7 Nov 2017 22:30:16 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> Message-ID: <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> Christian Heimes wrote: > On 2017-11-07 13:58, Ilya Etingof wrote: >> >> Exactly! This patch should not compromise current compatibility >> situation, but only extend it to current pyasn1 API. >> >> Thank you Christian for porting the patch! > > Here is a new patch. I tested it with FreeIPA's ipa-dnskeysyncd. I've looked at this patch a bit closer. Hmmpf! We should have automated tests for all the control stuff. In case of persistent search this is not so easy because OpenLDAP's slapd does not support it. I'd also like to know whether there could be a more elegant solution to avoid all the additional if-conditions. I'm concerned that it makes maintaining the code even more complicated. @Ilya: Would it be possible to try importing this new sentinel object and mimique its behaviour with a small custom class in case of older pyasn1 version without this sentinel object? Or could this new sentinel object made compatible with a check "is None"? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ilya at glas.net Tue Nov 7 17:21:48 2017 From: ilya at glas.net (Ilya Etingof) Date: Tue, 7 Nov 2017 23:21:48 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> Message-ID: <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> @Michael: Would it be possible to bump pyasn1 version requirement at python-ldap to 0.3+ and remove all these `if xxx is None` comparisons? I guess not because that might be against versioning policies. To my understanding the `is` operator can't be overloaded because it is a memory address comparison. May be we could inject the `NoValue` class along with the `noValue` singleton object into? pyasn1 from the python-ldap code at import time: ??? from pyasn1.type import univ ??? try: ??????? univ.noValue ??? except AttributeError: ??????? univ.NoValue = univ.noValue = None What would let us remove all these nasty `if xxx is None or? ... ` pieces from python-ldap code. Would that work? On 11/07/2017 10:30 PM, Michael Str?der wrote: > Christian Heimes wrote: >> On 2017-11-07 13:58, Ilya Etingof wrote: >>> Exactly! This patch should not compromise current compatibility >>> situation, but only extend it to current pyasn1 API. >>> >>> Thank you Christian for porting the patch! >> Here is a new patch. I tested it with FreeIPA's ipa-dnskeysyncd. > I've looked at this patch a bit closer. > > Hmmpf! We should have automated tests for all the control stuff. In case > of persistent search this is not so easy because OpenLDAP's slapd does > not support it. > > I'd also like to know whether there could be a more elegant solution to > avoid all the additional if-conditions. I'm concerned that it makes > maintaining the code even more complicated. > > @Ilya: > Would it be possible to try importing this new sentinel object and > mimique its behaviour with a small custom class in case of older pyasn1 > version without this sentinel object? > Or could this new sentinel object made compatible with a check "is None"? > > Ciao, Michael. > From michael at stroeder.com Wed Nov 8 06:19:07 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 8 Nov 2017 12:19:07 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> Message-ID: <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> Ilya Etingof wrote: > Would it be possible to bump pyasn1 version requirement at python-ldap > to 0.3+ and remove all these `if xxx is None` comparisons? I guess not > because that might be against versioning policies. Well, there is no versioning policy. Therefore we can define whatever is most suitable. ;-) Possible solution: - set strict requirement for python-ldap 2.4.x to pyasn1 < 0.3.x - set requirement for an upcoming python-ldap 2.5.x to pyasn1 >= 0.3.x Therefore if we don't find another solution I could cut a 2.4.46 release now containing recent minor changes and immediately start with 2.5.x adding a modification of your patches. All people installing/upgrading from PyPI would be happy with python-ldap 2.5.x and pyasn1 0.3.x. Not sure about people installing from OS distro packages though. I don't have an overview whether there's already a distro release with incompatible combination. @Ilya: Can you oversee which distros already ship with pyasn1 0.3.x? > To my understanding the `is` operator can't be overloaded because it is > a memory address comparison. Yes. > May be we could inject the `NoValue` class along with the `noValue` > singleton object into? pyasn1 from the python-ldap code at import time: > > ??? from pyasn1.type import univ > > ??? try: > ??????? univ.noValue > > ??? except AttributeError: > ??????? univ.NoValue = univ.noValue = None > > What would let us remove all these nasty `if xxx is None or? ... ` > pieces from python-ldap code. > > Would that work? I thought of something like this. But what would the if condition look like? With the above this if-expression would not work: if not cookie.hasValue(): Or am I missing something? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Sat Nov 11 14:56:05 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 11 Nov 2017 20:56:05 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> Message-ID: <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> Michael Str?der wrote: > All people installing/upgrading > from PyPI would be happy with python-ldap 2.5.x and pyasn1 0.3.x. I've decided to start 2.5.0 incorporating this patch without the backward-compability expressions. But I have some doubts. For example in class SSSResponseControl I now see this code: attribute_type_error = p.getComponentByName('attributeType') if attribute_type_error.hasValue(): self.attribute_type_error = attribute_type_error This does not set class attribute attribute_type_error at all in case there was no error. So this also changes the API for the calling application because instead of checking for foo_sss.attribute_type_error is None it has to check for hasattr(foo_sss, 'attribute_type_error') Hmm, I could implement a custom ResponseControl.__getattr__() which returns None in case of non-existent but known class attributes. But frankly it would be more nice if pyasn1 method getComponentByName() would take another optional parameter for default value returned in case of .hasValue()==False. So I could simply define a default value (here None) p.getComponentByName('attributeType', None) and be done with it. This would avoid a lot of if-statements with .hasValue() and the ResponseControl.__getattr__() workaround. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Sat Nov 11 15:31:48 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 11 Nov 2017 21:31:48 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> Message-ID: <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> Although I'm not happy with all the if-statements I've committed a slightly modified version of your submitted patch. Please review CVS HEAD now! Ciao, Michael. P.S.: Yes, I will provide another VCS repo soon because SF shuts down CVS at 2017-11-30. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ilya at glas.net Sat Nov 11 15:55:56 2017 From: ilya at glas.net (Ilya Etingof) Date: Sat, 11 Nov 2017 21:55:56 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> Message-ID: Hi Michael, Thanks for looking in this! > On 11 Nov 2017, at 20:56, Michael Str?der wrote: > > Michael Str?der wrote: >> All people installing/upgrading >> from PyPI would be happy with python-ldap 2.5.x and pyasn1 0.3.x. > > I've decided to start 2.5.0 incorporating this patch without the > backward-compability expressions. But I have some doubts. > > For example in class SSSResponseControl I now see this code: > > attribute_type_error = p.getComponentByName('attributeType') > if attribute_type_error.hasValue(): > self.attribute_type_error = attribute_type_error > > This does not set class attribute attribute_type_error at all in case > there was no error. So this also changes the API for the calling > application because instead of checking for > > foo_sss.attribute_type_error is None > > it has to check for > > hasattr(foo_sss, ?attribute_type_error') I might be looking at the wrong patch: https://github.com/pyldap/pyldap/pull/126/files#diff-184de394f72e23df85150ec1679a77e2L126 But there the instance attribute `attribute_type_error` is always set to either `None` or a value object. Please, point me to the right patch to take a look. The behavior you described looks backward-incompatible indeed! > Hmm, I could implement a custom ResponseControl.__getattr__() which > returns None in case of non-existent but known class attributes. Hold on! May be we could keep things simpler! ;-) > But frankly it would be more nice if pyasn1 method getComponentByName() > would take another optional parameter for default value returned in case > of .hasValue()==False. > > So I could simply define a default value (here None) > > p.getComponentByName('attributeType', None) > > and be done with it. This would avoid a lot of if-statements with > .hasValue() and the ResponseControl.__getattr__() workaround. Makes sense! Let me come up with an implementation shortly. > > Ciao, Michael. > From michael at stroeder.com Sat Nov 11 16:03:46 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 11 Nov 2017 22:03:46 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> Message-ID: <95f3a88f-a691-13e6-526d-b23114e0b9b2@stroeder.com> Ilya Etingof wrote: > On 11 Nov 2017, at 20:56, Michael Str?der wrote: >> I've decided to start 2.5.0 incorporating this patch without the >> backward-compability expressions. But I have some doubts. >> >> For example in class SSSResponseControl I now see this code: >> >> attribute_type_error = p.getComponentByName('attributeType') >> if attribute_type_error.hasValue(): >> self.attribute_type_error = attribute_type_error >> >> This does not set class attribute attribute_type_error at all in case >> there was no error. So this also changes the API for the calling >> application because instead of checking for >> >> foo_sss.attribute_type_error is None >> >> it has to check for >> >> hasattr(foo_sss, ?attribute_type_error') > > I might be looking at the wrong patch: > > https://github.com/pyldap/pyldap/pull/126/files#diff-184de394f72e23df85150ec1679a77e2L126 > > But there the instance attribute `attribute_type_error` is always set to either `None` or a value object. Seems the back-port following patch sent to the list was incomplete. Nevermind. I've corrected it. >> But frankly it would be more nice if pyasn1 method getComponentByName() >> would take another optional parameter for default value returned in case >> of .hasValue()==False. >> >> So I could simply define a default value (here None) >> >> p.getComponentByName('attributeType', None) >> >> and be done with it. This would avoid a lot of if-statements with >> .hasValue() and the ResponseControl.__getattr__() workaround. > > Makes sense! Let me come up with an implementation shortly. Would be awesome. Looking forward to it. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ilya at glas.net Sat Nov 11 16:41:04 2017 From: ilya at glas.net (Ilya Etingof) Date: Sat, 11 Nov 2017 22:41:04 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> Message-ID: <8E96B1E1-B3EA-4C1F-8CF6-072CB042E452@glas.net> LGTM. I?d only suggest slight re-wording for this piece of code: self.result = int(p.getComponentByName('virtualListViewResult')) self.result_code = p.getComponentByName(?virtualListViewResult?).prettyOut(self.result) Into something like this mostly for clarity: self.result = int(p.getComponentByName('virtualListViewResult')) self.result_code = p.getComponentByName(?virtualListViewResult?).prettyPrint() ps. I?m working on adding defaults to the pyasn1 getters. > On 11 Nov 2017, at 21:31, Michael Str?der wrote: > > Although I'm not happy with all the if-statements I've committed a > slightly modified version of your submitted patch. > > Please review CVS HEAD now! > > Ciao, Michael. > > P.S.: > Yes, I will provide another VCS repo soon because SF shuts down CVS at > 2017-11-30. > From michael at stroeder.com Sat Nov 11 17:34:06 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 11 Nov 2017 23:34:06 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <8E96B1E1-B3EA-4C1F-8CF6-072CB042E452@glas.net> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> <8E96B1E1-B3EA-4C1F-8CF6-072CB042E452@glas.net> Message-ID: <1268d818-fc31-06bb-c9b6-69558294927b@stroeder.com> Ilya Etingof wrote: > I?d only suggest slight re-wording for this piece of code: > > self.result = int(p.getComponentByName('virtualListViewResult')) > self.result_code = p.getComponentByName(?virtualListViewResult?).prettyOut(self.result) > > Into something like this mostly for clarity: > > self.result = int(p.getComponentByName('virtualListViewResult')) > self.result_code = p.getComponentByName(?virtualListViewResult?).prettyPrint() When reviewing sss.py and vlv.py I wondered why I've accepted those modules like this back then. Especially I wonder whether attribute .result_code should be set at all because the calling application could easily invoke .prettyPrint() itself if needed. I'm inclined to drop those lines for sake of performance. > ps. I?m working on adding defaults to the pyasn1 getters. Great! Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Sun Nov 12 07:55:13 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sun, 12 Nov 2017 13:55:13 +0100 Subject: [python-ldap] Anyone using python-ldap's dsml module? In-Reply-To: References: Message-ID: <49137ff5-f12f-4234-1c10-04178946ac1d@stroeder.com> Michael Str?der wrote: > Is anyone here using the dsml module shipped with python-ldap? > > Rather I'd like to drop dsml module from python-ldap for these reasons: > - it only supports DSMLv1 > - AFAIK no-one uses it anyway > - it's stand-alone and could be easily shipped as separate module if needed > - I have no spare-time maintaining it > > So if anyone would like use it any longer speak up now. I did not here from anyone that module dsml is of any use. It will be dropped in python-ldap 2.5.0+. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Sun Nov 12 09:24:04 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sun, 12 Nov 2017 15:24:04 +0100 Subject: [python-ldap] FYI: Minimum Python 2.7 for upcoming python-ldap 2.5.0 Message-ID: <83557c52-b775-f9c0-0375-7185c72b462c@stroeder.com> HI! I've decided that only Python 2.7.x will be officially supported by upcoming python-ldap 2.5.0. This gives us the possibility to e.g. use bytes() etc. Is anyone here aware of some aspects which would require a newer minor version than 2.7.0? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Sun Nov 12 10:55:10 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sun, 12 Nov 2017 16:55:10 +0100 Subject: [python-ldap] anyone using VLVResponseControl.result_code and SSSResponseControl.result_code? Message-ID: <0bd0cdcc-d778-363e-d0a8-8ee046da6597@stroeder.com> HI! Is anyone really using VLVResponseControl.result_code and SSSResponseControl.result_code? It contains pyasn1's .prettyPrint() output for the object already present in the real result's class attribute. In upcoming 2.5.0 I'd like to avoid setting these class attributes because the calling application can easily call method .prettyPrint() of the result class attribute if needed. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Sun Nov 12 12:45:49 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sun, 12 Nov 2017 18:45:49 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.1 Message-ID: <89697296-25fe-0eed-15a1-23e35e159ae7@stroeder.com> Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.5.1 python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.5.1 2017-11-12 Changes since 2.4.45: Mandatory prerequisites: - Python 2.7.x - pyasn1 0.3.7+ and pyasn1_modules 0.1.5+ Modules/ * removed unused code schema.c Lib/ * ldap.__version__, ldap.__author__ and ldap.__license__ now imported from new sub-module ldap.pkginfo also to setup.py * Added safety assertion when importing _ldap: ldap.pkginfo.__version__ must match _ldap.__version__ * removed stand-alone module dsml * slapdtest.SlapdObject.restart() just restarts slapd without cleaning any data * Compability changes for pyasn1 0.3.x or newer (thanks to Ilya Etingof and Christian Heimes) * The methods SSSResponseControl.decodeControlValue() and VLVResponseControl.decodeControlValue() now follow the coding convention to use camel-cased ASN.1 name as class attribute name. The old class names are still set for back-ward compability but should not be used in new code because they might be removed in a later release. * removed SSSRequestControl from ldap.controls.KNOWN_RESPONSE_CONTROLS Tests/ * added explicit reconnect tests for ReconnectLDAPObject ---------------------------------------------------------------- Released 2.4.45 2017-10-09 Changes since 2.4.44: Lib/ * Fixed reraising of wrong exception in SimpleLDAPObject._ldap_call() (thanks to Aigars Grins) Tests/ * removed work-around in t_cext.py ---------------------------------------------------------------- Released 2.4.44 2017-09-08 Changes since 2.4.43: Modules/ * more fine-grained GIL releasing in function l_ldap_result4() -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ilya at glas.net Sun Nov 12 16:30:15 2017 From: ilya at glas.net (Ilya Etingof) Date: Sun, 12 Nov 2017 22:30:15 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <1268d818-fc31-06bb-c9b6-69558294927b@stroeder.com> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> <8E96B1E1-B3EA-4C1F-8CF6-072CB042E452@glas.net> <1268d818-fc31-06bb-c9b6-69558294927b@stroeder.com> Message-ID: <61C0F77D-901A-4662-B629-A0D56467AE58@glas.net> Hi Michael, Here is my first take on the `default` feature: https://github.com/etingof/pyasn1/pull/100 I appreciate your suggestions and feedback! Thanks! > On 11 Nov 2017, at 23:34, Michael Str?der wrote: > > Ilya Etingof wrote: >> I?d only suggest slight re-wording for this piece of code: >> >> self.result = int(p.getComponentByName('virtualListViewResult')) >> self.result_code = p.getComponentByName(?virtualListViewResult?).prettyOut(self.result) >> >> Into something like this mostly for clarity: >> >> self.result = int(p.getComponentByName('virtualListViewResult')) >> self.result_code = p.getComponentByName(?virtualListViewResult?).prettyPrint() > > When reviewing sss.py and vlv.py I wondered why I've accepted those > modules like this back then. > > Especially I wonder whether attribute .result_code should be set at all > because the calling application could easily invoke .prettyPrint() > itself if needed. > > I'm inclined to drop those lines for sake of performance. > >> ps. I?m working on adding defaults to the pyasn1 getters. > > Great! > > Ciao, Michael. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Nov 13 06:42:49 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 13 Nov 2017 12:42:49 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <61C0F77D-901A-4662-B629-A0D56467AE58@glas.net> References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> <8E96B1E1-B3EA-4C1F-8CF6-072CB042E452@glas.net> <1268d818-fc31-06bb-c9b6-69558294927b@stroeder.com> <61C0F77D-901A-4662-B629-A0D56467AE58@glas.net> Message-ID: Ilya Etingof wrote: > Here is my first take on the `default` feature: > > ? ??https://github.com/etingof/pyasn1/pull/100 Looks good to me. > I appreciate your suggestions and feedback! And I'm really glad you're working on it so quickly. Do you have plans to release 0.4.1 soon? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ilya at glas.net Mon Nov 13 06:45:42 2017 From: ilya at glas.net (Ilya Etingof) Date: Mon, 13 Nov 2017 12:45:42 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> <8E96B1E1-B3EA-4C1F-8CF6-072CB042E452@glas.net> <1268d818-fc31-06bb-c9b6-69558294927b@stroeder.com> <61C0F77D-901A-4662-B629-A0D56467AE58@glas.net> Message-ID: Hi Michael, I am planning to release 0.4.1 by the end of this week. On 11/13/2017 12:42 PM, Michael Str?der wrote: > Ilya Etingof wrote: >> Here is my first take on the `default` feature: >> >> ? ??https://github.com/etingof/pyasn1/pull/100 > > Looks good to me. > >> I appreciate your suggestions and feedback! > > And I'm really glad you're working on it so quickly. > > Do you have plans to release 0.4.1 soon? > > Ciao, Michael. > From william at blackhats.net.au Tue Nov 14 01:05:13 2017 From: william at blackhats.net.au (William Brown) Date: Tue, 14 Nov 2017 16:05:13 +1000 Subject: [python-ldap] Issue with sasl binds Message-ID: <1510639513.4395.49.camel@blackhats.net.au> Hi there, I have a very odd issue. I can properly use ldapwhoami from the cli with TLS EXTERNAL: LDAPTLS_KEY=/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key LDAPTLS_CERT=/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt LDAPTLS_CACERT=/opt/dirsrv/etc/dirsrv/ssca/ca.crt ldapwhoami -Y EXTERNAL -H ldaps://localhost:63601/ SASL/EXTERNAL authentication started SASL username: cn=testuser_a,o=testing,l=389ds,st=Queensland,c=AU SASL SSF: 0 dn: cn=testuser_a,O=testing,L=389ds,ST=Queensland,C=AU However, the same with python-ldap does not work. import ldap tls_locs = { 'ca': '/opt/dirsrv/etc/dirsrv/ssca/ca.crt', 'crt': '/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt', 'key': '/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key', } ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_locs['ca']) conn = ldap.initialize('ldaps://localhost:63601') conn.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_locs['ca']) conn.set_option(ldap.OPT_X_TLS_CERTFILE, tls_locs['crt']) conn.set_option(ldap.OPT_X_TLS_KEYFILE, tls_locs['key']) print(conn.get_option(ldap.OPT_X_TLS_CACERTFILE)) print(conn.get_option(ldap.OPT_X_TLS_CERTFILE)) print(conn.get_option(ldap.OPT_X_TLS_KEYFILE)) sasl_auth = ldap.sasl.external() conn.sasl_interactive_bind_s("", sasl_auth) assert(conn.whoami_s().lower() == "dn: %s" % dn.lower()) conn.unbind_s() ---------- /opt/dirsrv/etc/dirsrv/ssca/ca.crt /opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt /opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key Traceback (most recent call last): ? File "works.py", line 23, in ????conn.sasl_interactive_bind_s("", sasl_auth) ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 410, in sasl_interactive_bind_s ????return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControl Tuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 265, in _ldap_call ????result = func(*args,**kwargs) ldap.AUTH_UNKNOWN: {'desc': 'Unknown authentication method', 'info': 'SASL(-4): no mechanism available: '} I'm really quite stumped on this one, and what's going on. Trace level 9 has no real extra help here. It seems like a problem with actually detecting the available mechs, because the server logs don't get far at all: [14/Nov/2017:16:03:56.517461686 +1000] conn=9 fd=64 slot=64 SSL connection from ::1 to ::1 [14/Nov/2017:16:03:56.536788945 +1000] conn=9 TLS1.2 128-bit AES-GCM [14/Nov/2017:16:03:56.556707754 +1000] conn=9 op=0 UNBIND [14/Nov/2017:16:03:56.556823805 +1000] conn=9 op=0 fd=64 closed - U1 Ideas? note: affects pyldap as well. From william at blackhats.net.au Tue Nov 14 01:07:28 2017 From: william at blackhats.net.au (William Brown) Date: Tue, 14 Nov 2017 16:07:28 +1000 Subject: [python-ldap] Issue with sasl binds In-Reply-To: <1510639513.4395.49.camel@blackhats.net.au> References: <1510639513.4395.49.camel@blackhats.net.au> Message-ID: <1510639648.4395.50.camel@blackhats.net.au> On Tue, 2017-11-14 at 16:05 +1000, William Brown wrote: > Hi there, > > I have a very odd issue. > > I can properly use ldapwhoami from the cli with TLS EXTERNAL: > > LDAPTLS_KEY=/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key > LDAPTLS_CERT=/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt > LDAPTLS_CACERT=/opt/dirsrv/etc/dirsrv/ssca/ca.crt ldapwhoami -Y > EXTERNAL -H ldaps://localhost:63601/ > > SASL/EXTERNAL authentication started > SASL username: cn=testuser_a,o=testing,l=389ds,st=Queensland,c=AU > SASL SSF: 0 > dn: cn=testuser_a,O=testing,L=389ds,ST=Queensland,C=AU > > However, the same with python-ldap does not work. > > import ldap > > tls_locs = { > 'ca': '/opt/dirsrv/etc/dirsrv/ssca/ca.crt', > 'crt': '/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt', > 'key': '/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key', > } > > ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_locs['ca']) > > conn = ldap.initialize('ldaps://localhost:63601') > > conn.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_locs['ca']) > conn.set_option(ldap.OPT_X_TLS_CERTFILE, tls_locs['crt']) > conn.set_option(ldap.OPT_X_TLS_KEYFILE, tls_locs['key']) > > print(conn.get_option(ldap.OPT_X_TLS_CACERTFILE)) > print(conn.get_option(ldap.OPT_X_TLS_CERTFILE)) > print(conn.get_option(ldap.OPT_X_TLS_KEYFILE)) > > sasl_auth = ldap.sasl.external() > conn.sasl_interactive_bind_s("", sasl_auth) > > assert(conn.whoami_s().lower() == "dn: %s" % dn.lower()) > conn.unbind_s() > > > ---------- > > /opt/dirsrv/etc/dirsrv/ssca/ca.crt > /opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt > /opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key > Traceback (most recent call last): > ? File "works.py", line 23, in > ????conn.sasl_interactive_bind_s("", sasl_auth) > ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line > 410, in sasl_interactive_bind_s > ????return > self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestContr > ol > Tuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) > ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line > 265, in _ldap_call > ????result = func(*args,**kwargs) > ldap.AUTH_UNKNOWN: {'desc': 'Unknown authentication method', 'info': > 'SASL(-4): no mechanism available: '} > > I'm really quite stumped on this one, and what's going on. Trace > level > 9 has no real extra help here. It seems like a problem with actually > detecting the available mechs, because the server logs don't get far > at > all: > > [14/Nov/2017:16:03:56.517461686 +1000] conn=9 fd=64 slot=64 SSL > connection from ::1 to ::1 > [14/Nov/2017:16:03:56.536788945 +1000] conn=9 TLS1.2 128-bit AES-GCM > [14/Nov/2017:16:03:56.556707754 +1000] conn=9 op=0 UNBIND > [14/Nov/2017:16:03:56.556823805 +1000] conn=9 op=0 fd=64 closed - U1 > > Ideas?? > > note: affects pyldap as well. > Sorry, sent the pyldap output for python 3.6. Here's the 2.7 output for python-ldap: /opt/dirsrv/etc/dirsrv/ssca/ca.crt /opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt /opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key Traceback (most recent call last): ? File "works.py", line 23, in ????conn.sasl_interactive_bind_s("", sasl_auth) ? File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 244, in sasl_interactive_bind_s ????return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControl Tuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) ? File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in _ldap_call ????result = func(*args,**kwargs) ldap.AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication method'} > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > https://mail.python.org/mailman/listinfo/python-ldap From michael at stroeder.com Tue Nov 14 03:54:28 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 14 Nov 2017 09:54:28 +0100 Subject: [python-ldap] Issue with sasl binds In-Reply-To: <1510639513.4395.49.camel@blackhats.net.au> References: <1510639513.4395.49.camel@blackhats.net.au> Message-ID: William Brown wrote: > I can properly use ldapwhoami from the cli with TLS EXTERNAL: > > LDAPTLS_KEY=/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key > LDAPTLS_CERT=/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt > LDAPTLS_CACERT=/opt/dirsrv/etc/dirsrv/ssca/ca.crt ldapwhoami -Y > EXTERNAL -H ldaps://localhost:63601/ > > SASL/EXTERNAL authentication started > SASL username: cn=testuser_a,o=testing,l=389ds,st=Queensland,c=AU > SASL SSF: 0 > dn: cn=testuser_a,O=testing,L=389ds,ST=Queensland,C=AU > > However, the same with python-ldap does not work. > > import ldap > > tls_locs = { > 'ca': '/opt/dirsrv/etc/dirsrv/ssca/ca.crt', > 'crt': '/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt', > 'key': '/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key', > } > > ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_locs['ca']) > > conn = ldap.initialize('ldaps://localhost:63601') > > conn.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_locs['ca']) > conn.set_option(ldap.OPT_X_TLS_CERTFILE, tls_locs['crt']) > conn.set_option(ldap.OPT_X_TLS_KEYFILE, tls_locs['key']) > > print(conn.get_option(ldap.OPT_X_TLS_CACERTFILE)) > print(conn.get_option(ldap.OPT_X_TLS_CERTFILE)) > print(conn.get_option(ldap.OPT_X_TLS_KEYFILE)) > > sasl_auth = ldap.sasl.external() > conn.sasl_interactive_bind_s("", sasl_auth) > > assert(conn.whoami_s().lower() == "dn: %s" % dn.lower()) > conn.unbind_s() > [..] > ldap.AUTH_UNKNOWN: {'desc': 'Unknown authentication method', 'info': > 'SASL(-4): no mechanism available: '} You typically get this error when TLS client cert was not used. python-ldap is a wrapper above libldap and therefore inherits some of its strange API characteristics. In this case it's the initialization of the SSL context. You have to use conn.set_option(ldap.OPT_X_TLS_NEWCTX, 0) *after* setting *all* connection-specific TLS options which AFAIK triggers creating a new SSLContext in libldap. The alternative is to set the options globally just like you did with ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, ?). But this does not work if your application wants to have connections with different TLS parameters. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From william at blackhats.net.au Tue Nov 14 17:53:45 2017 From: william at blackhats.net.au (William Brown) Date: Wed, 15 Nov 2017 08:53:45 +1000 Subject: [python-ldap] Issue with sasl binds In-Reply-To: References: <1510639513.4395.49.camel@blackhats.net.au> Message-ID: <1510700025.4395.60.camel@blackhats.net.au> On Tue, 2017-11-14 at 09:54 +0100, Michael Str?der wrote: > William Brown wrote: > > I can properly use ldapwhoami from the cli with TLS EXTERNAL: > > > > LDAPTLS_KEY=/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key > > LDAPTLS_CERT=/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt > > LDAPTLS_CACERT=/opt/dirsrv/etc/dirsrv/ssca/ca.crt ldapwhoami -Y > > EXTERNAL -H ldaps://localhost:63601/ > > > > SASL/EXTERNAL authentication started > > SASL username: cn=testuser_a,o=testing,l=389ds,st=Queensland,c=AU > > SASL SSF: 0 > > dn: cn=testuser_a,O=testing,L=389ds,ST=Queensland,C=AU > > > > However, the same with python-ldap does not work. > > > > import ldap > > > > tls_locs = { > > 'ca': '/opt/dirsrv/etc/dirsrv/ssca/ca.crt', > > 'crt': '/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.crt', > > 'key': '/opt/dirsrv/etc/dirsrv/ssca/user-testuser_a.key', > > } > > > > ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_locs['ca']) > > > > conn = ldap.initialize('ldaps://localhost:63601') > > > > conn.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_locs['ca']) > > conn.set_option(ldap.OPT_X_TLS_CERTFILE, tls_locs['crt']) > > conn.set_option(ldap.OPT_X_TLS_KEYFILE, tls_locs['key']) > > > > print(conn.get_option(ldap.OPT_X_TLS_CACERTFILE)) > > print(conn.get_option(ldap.OPT_X_TLS_CERTFILE)) > > print(conn.get_option(ldap.OPT_X_TLS_KEYFILE)) > > > > sasl_auth = ldap.sasl.external() > > conn.sasl_interactive_bind_s("", sasl_auth) > > > > assert(conn.whoami_s().lower() == "dn: %s" % dn.lower()) > > conn.unbind_s() > > [..] > > ldap.AUTH_UNKNOWN: {'desc': 'Unknown authentication method', > > 'info': > > 'SASL(-4): no mechanism available: '} > > You typically get this error when TLS client cert was not used. > > python-ldap is a wrapper above libldap and therefore inherits some of > its strange API characteristics. In this case it's the initialization > of > the SSL context. > > You have to use > > conn.set_option(ldap.OPT_X_TLS_NEWCTX, 0) > > *after* setting *all* connection-specific TLS options which AFAIK > triggers creating a new SSLContext in libldap. > > The alternative is to set the options globally just like you did with > ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, ?). But this does not work > if > your application wants to have connections with different TLS > parameters. Indeed. This does the trick. Thanks for that mate, > > Ciao, Michael. > From mhroncok at redhat.com Thu Nov 16 10:37:12 2017 From: mhroncok at redhat.com (=?UTF-8?Q?Miro_Hron=c4=8dok?=) Date: Thu, 16 Nov 2017 16:37:12 +0100 Subject: [python-ldap] [PATCH] Tests: Don't overwrite the server attribute of parent class Message-ID: Hi, We'd find out that the code in Tests/t_ldapobject.py::Test01_SimpleLDAPObject overwrites the server attribute of parent class by calling SlapdTestCase.setUpClass() directly. This might in some cases be problematic, as described in [0], a fix is to use super(). Attaching a patch for python-ldap. Source: [1] [0] https://github.com/pyldap/pyldap/pull/122 [1] https://github.com/pyldap/pyldap/pull/122#issuecomment-327441677 -- Miro Hron?ok -- Phone: +420777974800 IRC: mhroncok -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Tests-Don-t-overwrite-the-server-attribute-of-parent.patch Type: text/x-patch Size: 854 bytes Desc: not available URL: From michael at stroeder.com Thu Nov 16 11:02:18 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 16 Nov 2017 17:02:18 +0100 Subject: [python-ldap] [PATCH] Tests: Don't overwrite the server attribute of parent class In-Reply-To: References: Message-ID: <4fe6679f-fb08-6e4e-c1be-6f8ae03f12cf@stroeder.com> HI! Miro Hron?ok wrote: > We'd find out that the code in > Tests/t_ldapobject.py::Test01_SimpleLDAPObject overwrites the server > attribute of parent class by calling SlapdTestCase.setUpClass() > directly. This might in some cases be problematic, as described in [0], > a fix is to use super(). > [0] https://github.com/pyldap/pyldap/pull/122 Reading [0] it's my impression that you're relying on a false assumption: Let me state very clear that each instance of SlapdTestCase or a derived class is supposed to be used one-shot only and start its isolated slapd process and tear it down later. All current tests are and all future tests will be written based on this assumption. Nevertheless I agree that the class method should not change the class. > Attaching a patch for python-ldap. Source: [1] > [1] https://github.com/pyldap/pyldap/pull/122#issuecomment-327441677 I wonder why you only tweaked t_ldapobject.py because the very same call to SlapdTestCase.setUpClass() is also in t_cext.py. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Thu Nov 16 11:11:54 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 16 Nov 2017 17:11:54 +0100 Subject: [python-ldap] [PATCH] Tests: Don't overwrite the server attribute of parent class In-Reply-To: <4fe6679f-fb08-6e4e-c1be-6f8ae03f12cf@stroeder.com> References: <4fe6679f-fb08-6e4e-c1be-6f8ae03f12cf@stroeder.com> Message-ID: <094abfc1-b208-2a41-c81e-80d71abf1f12@stroeder.com> Michael Str?der wrote: > Nevertheless I agree that the class method should not change the class. > [..] > I wonder why you only tweaked t_ldapobject.py because the very same call > to SlapdTestCase.setUpClass() is also in t_cext.py. I've committed changes to t_cext.py and t_ldapobject.py to be released in 2.5.2. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From mhroncok at redhat.com Thu Nov 16 17:30:58 2017 From: mhroncok at redhat.com (=?UTF-8?Q?Miro_Hron=c4=8dok?=) Date: Thu, 16 Nov 2017 23:30:58 +0100 Subject: [python-ldap] [PATCH] Tests: Don't overwrite the server attribute of parent class In-Reply-To: <094abfc1-b208-2a41-c81e-80d71abf1f12@stroeder.com> References: <4fe6679f-fb08-6e4e-c1be-6f8ae03f12cf@stroeder.com> <094abfc1-b208-2a41-c81e-80d71abf1f12@stroeder.com> Message-ID: On 16.11.2017 17:11, Michael Str?der wrote: > Michael Str?der wrote: >> Nevertheless I agree that the class method should not change the class. >> [..] >> I wonder why you only tweaked t_ldapobject.py because the very same call >> to SlapdTestCase.setUpClass() is also in t_cext.py. That was because that particular place bit us and I forgot to look to other places. My mistake, sorry. > I've committed changes to t_cext.py and t_ldapobject.py to be released > in 2.5.2. Thank You. -- Miro Hron?ok -- Phone: +420777974800 IRC: mhroncok From michael at stroeder.com Sat Nov 18 09:25:01 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 18 Nov 2017 15:25:01 +0100 Subject: [python-ldap] Patch: ldap.syncrepl UUID constructors use bytes (Python 3 compatbility) In-Reply-To: References: <0FE49176-53F3-46EB-AFE6-CB3328923E35@stanford.edu> Message-ID: <88c1190c-92fd-58b1-b18f-fb0cd40755c6@stroeder.com> Karl, Michael Str?der wrote: > Karl Kornel wrote: >> The problem is this: In Python 3, the UUID class constructor?s ?bytes? input requires >> that you provide a bytes object. >> [..] >> This patch also works on test code I have in development >> (https://github.com/akkornel/syncrepl), running on Python 2.7 with python-ldap 2.4.38. >> But, I understand that you might not want to accept this until the t_syncrepl.py is >> more complete. > > Thanks for your submission. > > AFAIK the built-in function bytes() was introduced in Python 2.6. So unfortunately this > raises a question about back-ward compability to older Python versions. Now that python-ldap 2.5.x requires Python 2.7 I've committed your patch to HEAD. Please test. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ilya at glas.net Sun Nov 19 10:57:27 2017 From: ilya at glas.net (Ilya Etingof) Date: Sun, 19 Nov 2017 16:57:27 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> <8E96B1E1-B3EA-4C1F-8CF6-072CB042E452@glas.net> <1268d818-fc31-06bb-c9b6-69558294927b@stroeder.com> <61C0F77D-901A-4662-B629-A0D56467AE58@glas.net> Message-ID: Hi Michael, I think pyasn1 0.4.1 is mostly ready to be released. I have been trying to run relevant Python-LDAP tests with pyasn1 master [1] to make sure there are no regressions. Tests pass but I am not convinced they actually run through the pyasn1 code at all. So I wonder if you have a proper test bench handy to give it a quick try? Or teach me how to run them locally. Thanks! ;-) 1. https://github.com/etingof/pyasn1 > On 13 Nov 2017, at 12:42, Michael Str?der wrote: > > Ilya Etingof wrote: >> Here is my first take on the `default` feature: >> >> https://github.com/etingof/pyasn1/pull/100 > > Looks good to me. > >> I appreciate your suggestions and feedback! > > And I'm really glad you're working on it so quickly. > > Do you have plans to release 0.4.1 soon? > > Ciao, Michael. > From michael at stroeder.com Sun Nov 19 15:30:32 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sun, 19 Nov 2017 21:30:32 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: References: <88656222-46a1-8467-dc67-1a1490bc5f73@python.org> <51a310cf-8dcb-2ce1-ce6d-96369f1cda19@gmail.com> <8f66cc81-522f-effb-56df-fc49ca1ef90e@python.org> <8c0970ea-e001-434a-fc3f-c15a4a346a90@stroeder.com> <59227e39-93df-e80c-cec2-4dd05468e915@glas.net> <2d555270-2f8d-f77a-7435-3e67d1c1e025@stroeder.com> <24f2f654-d398-767e-9460-4cdbc13de91f@stroeder.com> <1f281b3a-5cba-b83d-a052-97e41e8980d4@stroeder.com> <8E96B1E1-B3EA-4C1F-8CF6-072CB042E452@glas.net> <1268d818-fc31-06bb-c9b6-69558294927b@stroeder.com> <61C0F77D-901A-4662-B629-A0D56467AE58@glas.net> Message-ID: Ilya Etingof wrote: > I think pyasn1 0.4.1 is mostly ready to be released. I have been > trying to run relevant Python-LDAP tests with pyasn1 master [1] to > make sure there are no regressions. Tests pass but I am not convinced > they actually run through the pyasn1 code at all. I'm afraid there's currently zero test coverage of pyasn1-related code in python-ldap. I will work on that. But for interop tests many of the controls would need full-featured build of OpenLDAP with all the overlays. You can look at scripts in Demo/pyasn1/ with syncrepl.py being the most complex one. BTW: I've committed many changes to CVS HEAD hunking out compat stuff for Python prior 2.7 and cleaning up the code in general. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From akkornel at stanford.edu Sun Nov 19 20:43:46 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Mon, 20 Nov 2017 01:43:46 +0000 Subject: [python-ldap] Patch: ldap.syncrepl UUID constructors use bytes (Python 3 compatbility) In-Reply-To: <88c1190c-92fd-58b1-b18f-fb0cd40755c6@stroeder.com> References: <0FE49176-53F3-46EB-AFE6-CB3328923E35@stanford.edu> <88c1190c-92fd-58b1-b18f-fb0cd40755c6@stroeder.com> Message-ID: Hi Michael, good evening! I have tested with the latest code from CVS. The Lib/ldap/syncrepl.py I have is CVS revision 1.12. Although I did get issues related to pyasn1, I did not get any bytes-related issues. So, I think this looks good! I?m sure that the pyldap maintainers will also appreciate not having to maintain an extra Python 3 modification, so thank you for that as well! ~ Karl On 11/18/17, 6:25 AM, "Michael Str?der" wrote: Karl, Michael Str?der wrote: > Karl Kornel wrote: >> The problem is this: In Python 3, the UUID class constructor?s ?bytes? input requires >> that you provide a bytes object. >> [..] >> This patch also works on test code I have in development >> (https://github.com/akkornel/syncrepl), running on Python 2.7 with python-ldap 2.4.38. >> But, I understand that you might not want to accept this until the t_syncrepl.py is >> more complete. > > Thanks for your submission. > > AFAIK the built-in function bytes() was introduced in Python 2.6. So unfortunately this > raises a question about back-ward compability to older Python versions. Now that python-ldap 2.5.x requires Python 2.7 I've committed your patch to HEAD. Please test. Ciao, Michael. From akkornel at stanford.edu Sun Nov 19 20:40:51 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Mon, 20 Nov 2017 01:40:51 +0000 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 Message-ID: Hi Ilya, good afternoon! I did once submit a patch to add some tests for syncrepl parts of python-ldap, as well as a modification to the test framework, so that syncrepl support would be active in the slapd used for testing. The post and attachments can be found here: https://mail.python.org/pipermail/python-ldap/2017q2/003923.html It has been some time since the submission, so I can not say right now if the patches would still work. But, one good thing is that I have access to a big LDAP directory! 8-) So I will test now the latest code from you, and the latest code from Michael, and I will let you know my results! Message: 1 Date: Sun, 19 Nov 2017 16:57:27 +0100 From: Ilya Etingof To: Michael Str?der Cc: Christian Heimes , python-ldap at python.org Subject: Re: [python-ldap] syncrepl fix for pyasn1 >= 0.3 Message-ID: Content-Type: text/plain; charset=utf-8 Hi Michael, I think pyasn1 0.4.1 is mostly ready to be released. I have been trying to run relevant Python-LDAP tests with pyasn1 master [1] to make sure there are no regressions. Tests pass but I am not convinced they actually run through the pyasn1 code at all. So I wonder if you have a proper test bench handy to give it a quick try? Or teach me how to run them locally. Thanks! ;-) 1. https://github.com/etingof/pyasn1 From akkornel at stanford.edu Sun Nov 19 20:39:59 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Mon, 20 Nov 2017 01:39:59 +0000 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 Message-ID: <9AC30598-69A1-432C-AD9C-156D586BF08D@stanford.edu> Hi Ilya and Michael, I was able to do testing using the latest versions of your code, and it seems that there is still some issue. * I used the pyasn1 from Git commit 1729162c76963233a702cddf4dadb43c3208f4f7 (`pyasn1.__version__` returns 0.4.1). * I used the latest python-ldap that I could get from CVS (`ldap.__version__` returns 2.5.1). I have CVS version 1.2 of the file Lib/ldap/syncrepl.py. The first test was to do a full syncrepl refresh of a directory. This is what would happen if you are setting up a client from nothing. The test completed successfully! The second test was to do another syncrepl refresh, but with my existing data as a starting point. That means the LDAP Server is having a cookie sent as part of the syncrepl search. The first reply back from the server triggers this trace: Traceback (most recent call last): File "/Users/akkornel/Library/Python/2.7/bin/syncrepl-client", line 6, in exec(compile(open(__file__).read(), __file__, 'exec')) File "/Users/akkornel/git/syncrepl/syncrepl-client", line 178, in loop_result = client.poll() File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 702, in poll all=1, timeout=3) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/python_ldap-2.5.2-py2.7-macosx-10.12-x86_64.egg/ldap/syncrepl.py", line 448, in syncrepl_poll sim = SyncInfoMessage(resp) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/python_ldap-2.5.2-py2.7-macosx-10.12-x86_64.egg/ldap/syncrepl.py", line 320, in __init__ if comp is not None and comp.hasValue(): AttributeError: 'SyncIdSet' object has no attribute 'hasValue' Looking at the LDAP trace, I see a Syncrepl Sync Info Message (from https://tools.ietf.org/html/rfc4533#section-2.5) is coming in. It looks like the LDAP server decided to send choice [3], the syncIdSet. But, that is an ASN.1 SEQUENCE, which I guess does not have the hasValue method. My third test was to delete my local data store, and to start a persistent Syncrepl search. Having no data store forced a complete refresh. Unfortunately, the refresh failed at the very end. In fact, I got a traceback in the same place as before, but with a different object. Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner self.run() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run self.__target(*self.__args, **self.__kwargs) File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 801, in run poll_result = self.poll() File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 702, in poll all=1, timeout=3) File "/Users/akkornel/git/python-ldap/Lib/ldap/syncrepl.py", line 448, in syncrepl_poll sim = SyncInfoMessage(resp) File "/Users/akkornel/git/python-ldap/Lib/ldap/syncrepl.py", line 320, in __init__ if comp is not None and comp.hasValue(): AttributeError: 'RefreshDelete' object has no attribute 'hasValue' So, this time it was a Syncrepl Sync Info Message containing a refreshDelete sequence. Just out of curiosity, I tried going back to pyasn1 version 0.2.3 (which I know worked with older versions of pyldap), and I got this exception: Traceback (most recent call last): File "/Users/akkornel/Library/Python/2.7/bin/syncrepl-client", line 6, in exec(compile(open(__file__).read(), __file__, 'exec')) File "/Users/akkornel/git/syncrepl/syncrepl-client", line 178, in loop_result = client.poll() File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 702, in poll all=1, timeout=3) File "/Users/akkornel/git/python-ldap/Lib/ldap/syncrepl.py", line 407, in syncrepl_poll all=0, File "/Users/akkornel/git/python-ldap/Lib/ldap/ldapobject.py", line 521, in result4 decoded_resp_ctrls = DecodeControlTuples(resp_ctrls,resp_ctrl_classes) File "/Users/akkornel/git/python-ldap/Lib/ldap/controls/__init__.py", line 150, in DecodeControlTuples control.decodeControlValue(encodedControlValue) File "/Users/akkornel/git/python-ldap/Lib/ldap/syncrepl.py", line 193, in decodeControlValue if cookie.hasValue(): AttributeError: 'NoneType' object has no attribute 'hasValue' python-ldap 2.4.45 and and pyasn1 0.2.3 work. If you would like me to try anything else, please let me know! Message: 1 Date: Sun, 19 Nov 2017 16:57:27 +0100 From: Ilya Etingof To: Michael Str?der Cc: Christian Heimes , python-ldap at python.org Subject: Re: [python-ldap] syncrepl fix for pyasn1 >= 0.3 Message-ID: Content-Type: text/plain; charset=utf-8 Hi Michael, I think pyasn1 0.4.1 is mostly ready to be released. I have been trying to run relevant Python-LDAP tests with pyasn1 master [1] to make sure there are no regressions. Tests pass but I am not convinced they actually run through the pyasn1 code at all. So I wonder if you have a proper test bench handy to give it a quick try? Or teach me how to run them locally. Thanks! ;-) 1. https://github.com/etingof/pyasn1 > On 13 Nov 2017, at 12:42, Michael Str?der wrote: > > Ilya Etingof wrote: >> Here is my first take on the `default` feature: >> >> https://github.com/etingof/pyasn1/pull/100 > > Looks good to me. > >> I appreciate your suggestions and feedback! > > And I'm really glad you're working on it so quickly. > > Do you have plans to release 0.4.1 soon? > > Ciao, Michael. > ------------------------------ Subject: Digest Footer _______________________________________________ python-ldap mailing list python-ldap at python.org https://mail.python.org/mailman/listinfo/python-ldap ------------------------------ End of python-ldap Digest, Vol 79, Issue 14 ******************************************* From akkornel at stanford.edu Mon Nov 20 03:25:34 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Mon, 20 Nov 2017 08:25:34 +0000 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: References: Message-ID: Hello! I have refreshed the patches, so now they work against the latest code in CVS. The patch to slapdtest.py is needed to enable the ?syncprov? overlay for slapd, which keeps track of changes and also makes the data available to clients. The second file contains the tests. They are only basic tests, but they are enough that it shows the issues I reported in my email from about 10 hours ago. I also have some notes describing additional tests that should be done, although I think they will need to be implemented in separate classes. I hope this helps! ~ Karl On 11/19/17, 5:40 PM, "Karl Kornel" wrote: Hi Ilya, good afternoon! I did once submit a patch to add some tests for syncrepl parts of python-ldap, as well as a modification to the test framework, so that syncrepl support would be active in the slapd used for testing. The post and attachments can be found here: https://mail.python.org/pipermail/python-ldap/2017q2/003923.html It has been some time since the submission, so I can not say right now if the patches would still work. But, one good thing is that I have access to a big LDAP directory! 8-) So I will test now the latest code from you, and the latest code from Michael, and I will let you know my results! Message: 1 Date: Sun, 19 Nov 2017 16:57:27 +0100 From: Ilya Etingof To: Michael Str?der Cc: Christian Heimes , python-ldap at python.org Subject: Re: [python-ldap] syncrepl fix for pyasn1 >= 0.3 Message-ID: Content-Type: text/plain; charset=utf-8 Hi Michael, I think pyasn1 0.4.1 is mostly ready to be released. I have been trying to run relevant Python-LDAP tests with pyasn1 master [1] to make sure there are no regressions. Tests pass but I am not convinced they actually run through the pyasn1 code at all. So I wonder if you have a proper test bench handy to give it a quick try? Or teach me how to run them locally. Thanks! ;-) 1. https://github.com/etingof/pyasn1 -------------- next part -------------- A non-text attachment was scrubbed... Name: t_syncrepl.py Type: text/x-python-script Size: 13073 bytes Desc: t_syncrepl.py URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: slapdtest.py.diff Type: application/octet-stream Size: 735 bytes Desc: slapdtest.py.diff URL: From michael at stroeder.com Mon Nov 20 05:31:11 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 20 Nov 2017 11:31:11 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: <9AC30598-69A1-432C-AD9C-156D586BF08D@stanford.edu> References: <9AC30598-69A1-432C-AD9C-156D586BF08D@stanford.edu> Message-ID: <60805b63-0f69-daf3-263b-5fde5b0da118@stroeder.com> Karl Kornel wrote: > I was able to do testing using the latest versions of your code, and it seems that there is still some issue. Could you please retest with latest CVS HEAD? Because I've polished Demo/pyasn1/syncrepl.py a bit and already fixed these issues. > * I used the latest python-ldap that I could get from CVS > (`ldap.__version__` returns 2.5.1). Please make sure that you really run latest python-ldap code from CVS HEAD which should already report __version__ 2.5.2. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Nov 20 06:46:04 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 20 Nov 2017 12:46:04 +0100 Subject: [python-ldap] syncrepl fix for pyasn1 >= 0.3 In-Reply-To: References: Message-ID: <244aadac-e74c-7021-ab45-80661460acb9@stroeder.com> Karl Kornel wrote: > I have refreshed the patches, so now they work against the latest code in CVS. Thank you! > The patch to slapdtest.py is needed to enable the ?syncprov? overlay for slapd, I've committed a slightly modified variant of your test module. Background: No need to patch slapdtest.py since it's meant to take an arbitrary template string (via sub-classing). You can even do more custom with sub-classing. E.g. in tests of ?-DIR's Python module I generate the config based on the Jinja2 templates in the ?-DIR ansible roles. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Nov 20 12:45:38 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 20 Nov 2017 18:45:38 +0100 Subject: [python-ldap] testing syncrepl refresh with restarted slapd In-Reply-To: <244aadac-e74c-7021-ab45-80661460acb9@stroeder.com> References: <244aadac-e74c-7021-ab45-80661460acb9@stroeder.com> Message-ID: <70bea692-59a2-c251-8a29-5ab483302864@stroeder.com> Michael Str?der wrote: > I've committed a slightly modified variant of your test module. > > Background: > No need to patch slapdtest.py since it's meant to take an arbitrary > template string (via sub-classing). > > You can even do more custom with sub-classing. E.g. in tests of ?-DIR's > Python module I generate the config based on the Jinja2 templates in the > ?-DIR ansible roles. BTW: Regarding your TODO section about testing refresh phase against a restarted slapd you can look into method Test01_ReconnectLDAPObject.test102_reconnect_simple_bind() in script Tests/t_ldapobject.py where slapd is restarted to test the proper reconnect. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Nov 20 12:53:19 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 20 Nov 2017 18:53:19 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 Message-ID: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.5.2 python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.5.2 2017-11-20 Changes since 2.5.1: * code-cleaning in setup.py Modules/ * PyBytes_ instead of PyString_ and added PyInt_FromLong compat macro * moved code from version.c to ldapmodule.c * removed obsolete back-ward compability constants from common.h * build checks whether LDAP_API_VERSION is OpenLDAP 2.4.x * _ldap.__author__ and _ldap.__license__ also set from ldap.pkginfo * assume C extension API for Python 2.7+ Lib/ * removed all dependencies on modules string and types * removed use of .has_key() * removed class ldap.ldapobject.NonblockingLDAPObject * new global constant ldap.LIBLDAP_API_INFO * right after importing _ldap there is a call into libldap to initialize it * method .decodeControlValue() of SSSResponseControl and VLVResponseControl does not set class attribute result_code anymore * always use bytes() for UUID() constructor in ldap.syncrepl * module ldif now uses functions b64encode() and b64decode() * fixed pickling and restoring of ReconnectLDAPObject * more modules with PEP-8 compliance * ldap.ldapobject split into module-package Tests/ * scripts do not directly call SlapdTestCase.setUpClass() anymore * added LDIF test with folded, base64-encoded attribute * added more tests for sub-module ldap.dn * added tests for ldap.syncrepl (thanks to Karl Kornel) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Nov 20 13:02:57 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 20 Nov 2017 19:02:57 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> Message-ID: Michael Str?der wrote: > Find a new release of python-ldap: > > https://pypi.python.org/pypi/python-ldap/2.5.2 A further note about this release: The massive code changes under the hood are mainly breaking the chains of back-ward compability to Python versions prior 2.7. It is meant as a major cleanup and is not fully finished yet. There might be an option for Python 3 support from here. Your code which worked with Python 2.7 and python-ldap up to 2.4.45 should still run without any issues. If there are any compat issues please let me know ASAP so I can quickly provide a fix. Developers who are stuck with Python versions prior 2.7 should still continue to use python-ldap 2.4.45. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From christian at python.org Mon Nov 20 14:11:22 2017 From: christian at python.org (Christian Heimes) Date: Mon, 20 Nov 2017 20:11:22 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> Message-ID: On 2017-11-20 19:02, Michael Str?der wrote: > Michael Str?der wrote: >> Find a new release of python-ldap: >> >> https://pypi.python.org/pypi/python-ldap/2.5.2 > > A further note about this release: > > The massive code changes under the hood are mainly breaking the chains > of back-ward compability to Python versions prior 2.7. It is meant as a > major cleanup and is not fully finished yet. There might be an option > for Python 3 support from here. > > Your code which worked with Python 2.7 and python-ldap up to 2.4.45 > should still run without any issues. If there are any compat issues > please let me know ASAP so I can quickly provide a fix. > > Developers who are stuck with Python versions prior 2.7 should still > continue to use python-ldap 2.4.45. Hi Michael, thanks for the new release! The option for Python 3 support in python-ldap is fantastic news. Rapha?l Barrois, Petr, Miro, and me have been working on a Python 3 fork [1] of python-ldap for a while. The fork has been shipped in Fedora for several releases and is used in production, e.g. FreeIPA. The fork stayed as close to python-ldap as possible because we never lost hope to get all Python 3 changes into upstream one day. I'm sure that my co-maintainers gladly agree to get rid of the fork ASAP. If you are interested to accept our fork back into python-ldap, then we should come up with a plan. How about we update pyldap to python-ldap 2.5.2 first? You can see a diff for 2.5.1 on github [2]. Regards, Christian [1] https://github.com/pyldap/pyldap/ [2] https://github.com/pyldap/pyldap/compare/cvs...master?expand=1 From michael at stroeder.com Mon Nov 20 14:23:34 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 20 Nov 2017 20:23:34 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> Message-ID: <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> Christian Heimes wrote: > The option for Python 3 support in python-ldap is fantastic news. > Rapha?l Barrois, Petr, Miro, and me have been working on a Python 3 fork > [1] of python-ldap for a while. The fork has been shipped in Fedora for > several releases and is used in production, e.g. FreeIPA. The fork > stayed as close to python-ldap as possible because we never lost hope to > get all Python 3 changes into upstream one day. I'm sure that my > co-maintainers gladly agree to get rid of the fork ASAP. Hmm. The main obstacle for back-porting pyldap is that I'd like to keep python-ldap binary-only and still let the calling app do the Unicode decode/encode stuff if needed. It seems you're endorsing the opposite way. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Mon Nov 20 14:52:10 2017 From: jdennis at redhat.com (John Dennis) Date: Mon, 20 Nov 2017 14:52:10 -0500 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> Message-ID: On 11/20/2017 02:23 PM, Michael Str?der wrote: > Hmm. The main obstacle for back-porting pyldap is that I'd like to keep > python-ldap binary-only and still let the calling app do the Unicode > decode/encode stuff if needed. It seems you're endorsing the opposite way. Why? What is your rationale for that? It seems entirely appropriate and user friendly for the binding to perform the UTF-8 encode/decode. Asking users to understand *and* never forget to apply all endcode/decode operations when handling LDAP data is large opportunity for errors as has been shown to be prevalent in the existing binding usage. Plus, doing the endcode/decode in the binding is super easy. So why not if it's easy and has been shown to greatly eliminate errors? -- John From raphael.barrois at m4x.org Mon Nov 20 15:18:49 2017 From: raphael.barrois at m4x.org (=?UTF-8?B?UmFwaGHDq2w=?= Barrois) Date: Mon, 20 Nov 2017 21:18:49 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> Message-ID: <20171120211849.37427cd9@anoth> On Mon, 20 Nov 2017 20:23:34 +0100 Michael Str?der wrote: > Christian Heimes wrote: > > The option for Python 3 support in python-ldap is fantastic news. > > Rapha?l Barrois, Petr, Miro, and me have been working on a Python 3 fork > > [1] of python-ldap for a while. The fork has been shipped in Fedora for > > several releases and is used in production, e.g. FreeIPA. The fork > > stayed as close to python-ldap as possible because we never lost hope to > > get all Python 3 changes into upstream one day. I'm sure that my > > co-maintainers gladly agree to get rid of the fork ASAP. > > Hmm. The main obstacle for back-porting pyldap is that I'd like to keep > python-ldap binary-only and still let the calling app do the Unicode > decode/encode stuff if needed. It seems you're endorsing the opposite way. > > Ciao, Michael. > Hi, The question of bytes/unicode in LDAP is rather complicated, and depends on the objects we're considering. Per the LDAP RFCs, a few fields *MUST* be valid UTF-8 strings: - An object's distinguishedName ; - An attribute name ? but not its value ; - A server URI ; - And a couple of others. This is the choice we made in pyldap: - If the field is mandated to be a valid UTF-8 string, expose it as a "unicode" object ; - Otherwise, it's bytes. In other words, a typical query would be (with explicit type markers for readability): >>> conn.search_ext_s(base=u'ou=people,dc=example,dc=org', scope=ldap.SCOPE_ONELEVEL, filterstr=u'(objectClass=inetOrgPerson') [ (u'uid=rbarrois,ou=people,dc=example,dc=org', { u'cn': [b"Rapha\xc3\xabl"], u'sn': [b"Barrois"], u'memberOf': [b"cn=test,ou=groups,dc=example,dc=org", b"cn=admin,ou=groups,dc=example,dc=org"], }), ] In the python-ldap style, each and every program calling `search_ext_s` would have to: - UTF-8 encode the `base` and `filterstr` parameters (although they must always be valid UTF-8) ; - UTF-8 decode each object's DN (although it can only be a valid UTF-8 string) ; - UTF-8 decode each attribute name (only UTF-8 is allowed as well). Beyond that, reading an attribute *value* depends on the underlying schema, and ? as you designed in python-ldap ? *MUST* be handled specifically by the application: the only common type here is "bytes". -- Rapha?l From michael at stroeder.com Mon Nov 20 18:55:53 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 21 Nov 2017 00:55:53 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> Message-ID: <0284e127-5baa-e476-a29f-27a4471dc830@stroeder.com> John Dennis wrote: > On 11/20/2017 02:23 PM, Michael Str?der wrote: >> Hmm. The main obstacle for back-porting pyldap is that I'd like to keep >> python-ldap binary-only and still let the calling app do the Unicode >> decode/encode stuff if needed. It seems you're endorsing the opposite >> way. > > Why? What is your rationale for that? > > It seems entirely appropriate and user friendly for the binding to > perform the UTF-8 encode/decode. As Rapha?l also pointed out it's a bit more complicated. Even in my higher-level code I often e.g. treat DNs or similar values opaque which are internally sent or received through LDAP controls. In this case decoding and re-encoding is unnecessary and error-prone. Many code parts have to be changed. Code passing in or out to the higher-level module should be Unicode if appropriate (if needed). > Asking users to understand *and* never forget to apply all > endcode/decode operations when handling LDAP data is large opportunity > for errors as has been shown to be prevalent in the existing binding > usage. Plus, doing the endcode/decode in the binding is super easy. So > why not if it's easy and has been shown to greatly eliminate errors? Hmm, please don't get it wrong. But your comment sounds a bit that you're mostly handling simple searches with strings going in and out which are known to be UTF-8. But that's not the case in general. IMO there should be a low-level, bytes-only module like python-ldap and the "user-friendly" part (for whatever definition of role "user") should be done in higher-level wrapper modules. Another point of view: Would you expect a low-level DNS module to handle Unicode decoding/encoding? Note that despite hostname conventions in the DNS protocol labels are OctetString. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Nov 20 19:13:38 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 21 Nov 2017 01:13:38 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: <0284e127-5baa-e476-a29f-27a4471dc830@stroeder.com> References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> <0284e127-5baa-e476-a29f-27a4471dc830@stroeder.com> Message-ID: <61af39ac-2647-c01b-af4e-7a62681d0957@stroeder.com> Michael Str?der wrote: > Even in my higher-level code I often e.g. treat DNs or similar values > opaque which are internally sent or received through LDAP controls. IIRC while there are likely no issues in our comfortable Western Latin character world Unicode has some interesting corner-cases. So decoding/re-encoding might not lead to the same results. Frankly I have next-to-zero knowledge about all the Unicode Normalization Forms. Or does anybody here spontaneously fully understand this? https://tools.ietf.org/html/rfc8264#section-5.2.4 Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From pviktori at redhat.com Tue Nov 21 05:18:43 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Nov 2017 11:18:43 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: <0284e127-5baa-e476-a29f-27a4471dc830@stroeder.com> References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> <0284e127-5baa-e476-a29f-27a4471dc830@stroeder.com> Message-ID: <42d98226-ed49-3b7f-079e-4e2910ec877f@redhat.com> On 11/21/2017 12:55 AM, Michael Str?der wrote: > John Dennis wrote: >> On 11/20/2017 02:23 PM, Michael Str?der wrote: >>> Hmm. The main obstacle for back-porting pyldap is that I'd like to keep >>> python-ldap binary-only and still let the calling app do the Unicode >>> decode/encode stuff if needed. It seems you're endorsing the opposite >>> way. >> >> Why? What is your rationale for that? >> >> It seems entirely appropriate and user friendly for the binding to >> perform the UTF-8 encode/decode. > > As Rapha?l also pointed out it's a bit more complicated. > > Even in my higher-level code I often e.g. treat DNs or similar values > opaque which are internally sent or received through LDAP controls. In > this case decoding and re-encoding is unnecessary and error-prone. Many > code parts have to be changed. Code passing in or out to the > higher-level module should be Unicode if appropriate (if needed). > >> Asking users to understand *and* never forget to apply all >> endcode/decode operations when handling LDAP data is large opportunity >> for errors as has been shown to be prevalent in the existing binding >> usage. Plus, doing the endcode/decode in the binding is super easy. So >> why not if it's easy and has been shown to greatly eliminate errors? > > Hmm, please don't get it wrong. But your comment sounds a bit that > you're mostly handling simple searches with strings going in and out > which are known to be UTF-8. But that's not the case in general. That's a wrong assumption on your side. We all agree here that attribute *values* should, at the python-ldap level, always be byte strings. Now, the question is about DNs, attribute names, and other data specified as UTF-8. I argue that if you wish to port to Python 3, rather than Python 3 syntax with C semantics, then str is the right choice. Note that UTF-8 encoding/decoding is quite fast. Especially so for ASCII. Also, DNs and attribute names tend to be short; I'd be surprised if you found the overhead is even measurable in a real-world application. > IMO there should be a low-level, bytes-only module like python-ldap and > the "user-friendly" part (for whatever definition of role "user") should > be done in higher-level wrapper modules. > > Another point of view: Would you expect a low-level DNS module to handle > Unicode decoding/encoding? Note that despite hostname conventions in the > DNS protocol labels are OctetString. A low-level DNS module should stick to specification. Similarly, in Python 3, "text with a known encoding" is usually represented as "str", so in the (simple) cases LDAP specs specify the encoding, that's what I argue for the wrapper should use. -- Petr Viktorin From michael at stroeder.com Tue Nov 21 05:31:26 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 21 Nov 2017 11:31:26 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: <42d98226-ed49-3b7f-079e-4e2910ec877f@redhat.com> References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> <0284e127-5baa-e476-a29f-27a4471dc830@stroeder.com> <42d98226-ed49-3b7f-079e-4e2910ec877f@redhat.com> Message-ID: <8266db6e-b433-a475-03a9-6644b6170e01@stroeder.com> Petr Viktorin wrote: > That's a wrong assumption on your side. We all agree here that attribute > *values* should, at the python-ldap level, always be byte strings. > [..] > Now, the question is about DNs, attribute names, and other data > specified as UTF-8. But what about the very specific values in extended controls and their direct use for further LDAP operations? AFAICS there's no work done in pyldap for this. Frankly I'm really upset that you changed the API while keep the module name space just because RedHat was too lazy to adjust own code. This is already causing conflicts with distro packages. The role of RedHat in this story is not really appealing. Personally I'm considering forking python-ldap into a separate name space to keep my own stuff working (with adapted import statements). Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From pviktori at redhat.com Tue Nov 21 05:38:31 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Nov 2017 11:38:31 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: <61af39ac-2647-c01b-af4e-7a62681d0957@stroeder.com> References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> <0284e127-5baa-e476-a29f-27a4471dc830@stroeder.com> <61af39ac-2647-c01b-af4e-7a62681d0957@stroeder.com> Message-ID: <928520fe-d5ba-f53a-c83c-4196fa69cc26@redhat.com> On 11/21/2017 01:13 AM, Michael Str?der wrote: > Michael Str?der wrote: >> Even in my higher-level code I often e.g. treat DNs or similar values >> opaque which are internally sent or received through LDAP controls. > > IIRC while there are likely no issues in our comfortable Western Latin > character world Unicode has some interesting corner-cases. So > decoding/re-encoding might not lead to the same results. Frankly I have > next-to-zero knowledge about all the Unicode Normalization Forms. Unicode Normalization forms are orthogonal to encoding/decoding. From the python-ldap point of view, normalization works at the level of the data, not its representation. Choosing to encode/decode doesn't bring any *new* normalization issues -- you can do normalization on an UTF-8 encoded bytestring. Here's an example diagram: "?" (one "character") --- KC normalization --> "fi" (two "characters") ^ ^ | UTF-8 encode/decode | UTF-8 v v bytes([239, 172, 129]) --- KC normalization --> bytes([102, 105]) You can leave normalizing attribute names or DNs entirely to the application developers (as it's done now, with bytestrings). Or you might choose to validate normal forms, or even auto-normalize, but that would be a separate, new feature. (And I don't think it would be a terribly useful feature for python-ldap.) -- Petr Viktorin From pviktori at redhat.com Tue Nov 21 06:05:24 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Nov 2017 12:05:24 +0100 Subject: [python-ldap] ANN: python-ldap 2.5.2 In-Reply-To: <8266db6e-b433-a475-03a9-6644b6170e01@stroeder.com> References: <00bd537c-3783-a5e9-8ebb-75dbb89c65eb@stroeder.com> <79f92036-b17f-7dcb-0a58-1d4803cd8f5f@stroeder.com> <0284e127-5baa-e476-a29f-27a4471dc830@stroeder.com> <42d98226-ed49-3b7f-079e-4e2910ec877f@redhat.com> <8266db6e-b433-a475-03a9-6644b6170e01@stroeder.com> Message-ID: On 11/21/2017 11:31 AM, Michael Str?der wrote: > Petr Viktorin wrote: >> That's a wrong assumption on your side. We all agree here that attribute >> *values* should, at the python-ldap level, always be byte strings. >> [..] >> Now, the question is about DNs, attribute names, and other data >> specified as UTF-8. > > But what about the very specific values in extended controls and their > direct use for further LDAP operations? AFAICS there's no work done in > pyldap for this. Right. In pyldap, in all cases where attribute values are to be used as text, they need to be decoded first ? whether they be names of people, descriptions, or, yes, attribute names. Porting any project to Python 3 involves deciding what is text and what is bytes, and changing appropriately. Almost always, some need to encode/decode will leak to the applications ? you can't really get away from that. We decided the text/bytes boundary, based both on the specs and on the needs of real-world projects that build on top of the library. Using the result feels that one is working with the language (Python 3), rather than against it. > Frankly I'm really upset that you changed the API while keep the module > name space just because RedHat was too lazy to adjust own code. This is > already causing conflicts with distro packages. The role of RedHat in > this story is not really appealing. Well, not everyone around the form, including the original author, is from Red Hat. Feel free to accuse me (who agreed with keeping the namespace, so we could continue using python-ldap for the cases where it can be used, i.e. in python2) or the FreeIPA project (who are the ones "lazy" to adjust imports), but who these developers work for is quite irrelevant in this case. Or blame Red Hat, if you want to blame it. But if you want a discussion, explanations, or other points of view, it'll be better to talk to the specific people. > Personally I'm considering forking python-ldap into a separate name > space to keep my own stuff working (with adapted import statements). That would be sad. We always wanted to contribute the pyldap changes back into python-ldap, when possible; this was even one of the major reasons for keeping the same import name. Before you go and fork, can we talk about other possible ways out? We do want to help the project, not hurt it ? but we're really struggling to see the best way for us to do that. -- Petr Viktorin From michael at stroeder.com Tue Nov 21 06:48:20 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 21 Nov 2017 12:48:20 +0100 Subject: [python-ldap] Future of python-ldap.org - get involved now! Message-ID: HI! I feel that I'm probably not the right one to work on module ldap anymore. So I'd like to step back as a maintainer of python-ldap.org. There are some work items to be done in the *very near* future: 1. Find a new VCS home (CVS write access at SF is closed 2017-11-30) 2. Take over hosting of domain python-ldap.org (current registration ends within few weeks) 3. Take over mailing list moderation Furthermore: 4. Get administrative access to PyPI Interested maintainers should contact me off-list so I can provide them with information especially needed to take over items 2., 3. and 4. I will help as much as I can to make the transition to be finished soon and without interruption. Thanks in advance for your support. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From pviktori at redhat.com Tue Nov 21 08:10:19 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Nov 2017 14:10:19 +0100 Subject: [python-ldap] Future of python-ldap.org - get involved now! In-Reply-To: References: Message-ID: <99781ad6-ff25-a428-4731-d9a7d3451557@redhat.com> On 11/21/2017 12:48 PM, Michael Str?der wrote: > HI! > > I feel that I'm probably not the right one to work on module ldap > anymore. So I'd like to step back as a maintainer of python-ldap.org. Hello, Thank you for maintaining python-ldap all this time! I'm sorry to see this e-mail, and hope we can find ways to collaborate in the future. I'll assume the decision is a well thought-out one, not just an immediate result of the current discussions; I'll write the rest with that in mind. > There are some work items to be done in the *very near* future: > > 1. Find a new VCS home (CVS write access at SF is closed 2017-11-30) > > 2. Take over hosting of domain python-ldap.org (current registration > ends within few weeks) > > 3. Take over mailing list moderation > > Furthermore: > > 4. Get administrative access to PyPI > > Interested maintainers should contact me off-list so I can provide them > with information especially needed to take over items 2., 3. and 4. > I will help as much as I can to make the transition to be finished soon > and without interruption. I can take over, with some caveats: - I'm an expert on Python, not LDAP: I could do general maintenance but not much new development. - I was paid to help projects transition to Python 3; any further involvement would be from my (limited) free time. - You and I have different opinions on how to port python-ldap to Python 3 (see discussion in the other thread); specifically, I think changes from the pyldap fork should be merged into python-ldap (ideally after re-review, if people are available). I can offer to: 1. Move to Git, hosted on Pagure (open-source, but not well known), with a mirror on GitHub (proprietary, but familiar to too many people and offers easy ways to run tests). 2. Host python-ldap.org as a static website on GitHub pages (as that's least work for me); put documentation on Read the Docs. 3. Take over mailing list moderation. 4. Merge Python3 changes from the pyldap project, and release on PyPI. - handle subsequent contributions (patches/pull requests) and releases, if other people do reviews. - Look for other interested maintainers. Let me know if it's enough. -- Petr Viktorin From william at blackhats.net.au Tue Nov 21 08:31:42 2017 From: william at blackhats.net.au (William Brown) Date: Tue, 21 Nov 2017 14:31:42 +0100 Subject: [python-ldap] Future of python-ldap.org - get involved now! In-Reply-To: References: Message-ID: <1511271102.7096.41.camel@blackhats.net.au> On Tue, 2017-11-21 at 12:48 +0100, Michael Str?der wrote: > HI! > > I feel that I'm probably not the right one to work on module ldap > anymore. So I'd like to step back as a maintainer of python-ldap.org. > > There are some work items to be done in the *very near* future: > > 1. Find a new VCS home (CVS write access at SF is closed 2017-11-30) > > 2. Take over hosting of domain python-ldap.org (current registration > ends within few weeks) > > 3. Take over mailing list moderation > > Furthermore: > > 4. Get administrative access to PyPI > > Interested maintainers should contact me off-list so I can provide > them > with information especially needed to take over items 2., 3. and 4. > I will help as much as I can to make the transition to be finished > soon > and without interruption. > > Thanks in advance for your support. > > Wow. Just want to say thank you for all your years of work on this library. I think many years ago, python-ldap really helped me to get interested in ldap and get to where I am now. This is an important library and I'm sure that someone will step up to maintain it. Thank you, William, From pviktori at redhat.com Tue Nov 21 10:46:12 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Nov 2017 16:46:12 +0100 Subject: [python-ldap] Future of python-ldap.org - an introduction, and a plan Message-ID: <46f51488-2e79-8072-734f-a7a5825e6911@redhat.com> Hello, As you might have heard, Michael Str?der decided to step down from maintaining python-ldap. Michael, I would like to thank you for the years of maintenance and development. Python's LDAP story would be nowhere near where it is now if it weren't for you. I hope to work together again in the future. Speaking of future: in a few days, SourceForge will shut down its CVS hosting. And as CVS is fading into obsolescence, Python 2 has a few last years of bugfix-only support left. The python-ldap project now needs something more than just new development and bug fixes. That's where I can help, so I've volunteered to step up as a new maintainer, provided that we don't find anyone better. I can't, of course, hope to replace Michael. I don't know that much about LDAP. My contributions will be mostly limited to the administration side of things. As for my background ? my day job is Python maintenance for Fedora-derived distros. I've been involved with pyldap, a fork of python-ldap that adds Python 3 support. I hope to bring Python 3 support into python-ldap, as that's the mission that originally brought me to this project. My current plan is: # Move to Git Git is currently the most popular open-source version control system, and also one I'm familiar with. The pyldap project has a branch of history imported from CVS, so conversion should not be a problem. # Move to GitHub and Pagure. GitHub (https://github.com/) is nowadays the most popular Git hosting provider. Its one big disadvantage is that it's closed-source and proprietary. Pagure (https://pagure.io/) is another Git hosting site, which is open-source. Hopefully that will work for those opposed to GitHub. (And plain old patch e-mails still work, of course.) # Moderate this list Starting today, I'm a moderator here at python-ldap at python.org. I hope to keep it a friendly place. # Move the documentation to Read the Docs https://readthedocs.org/ is quite a nice service for hosting Sphinx-based documentation. Let's put the docs there. # Move the website to Read the Docs If possible, I'll merge the website into the documentation, and point python-ldap.org there. If that doesn't work out for any reason, I'll search for another reliable free-of-charge hosting service for static webpages. # Merge changes from the pyldap project The Python 3 fork was, from the start, intended to be merged back if at all possible. If I get to maintain python-ldap, that's what will happen. If possible, I'd like to do it as a series of reviewed changes rather than import everything wholesale. # Continue maintaining After this I will, as my time allows, merge reviewed code, help with Python- or Git-related problems, moderate discussions, and generally make it possible for code authors and reviewers to do their work. If you have any comments or concerns, or would like to help, please speak up! -- Petr Viktorin From papachoco at gmail.com Tue Nov 21 11:47:58 2017 From: papachoco at gmail.com (Carlos Sanchez) Date: Tue, 21 Nov 2017 10:47:58 -0600 Subject: [python-ldap] Future of python-ldap.org - an introduction, and a plan In-Reply-To: <46f51488-2e79-8072-734f-a7a5825e6911@redhat.com> References: <46f51488-2e79-8072-734f-a7a5825e6911@redhat.com> Message-ID: Any plans for pypy/pypy3 support? Carlos On Tue, Nov 21, 2017 at 9:46 AM, Petr Viktorin wrote: > Hello, > As you might have heard, Michael Str?der decided to step down from > maintaining python-ldap. > > Michael, I would like to thank you for the years of maintenance and > development. Python's LDAP story would be nowhere near where it is now if > it weren't for you. > I hope to work together again in the future. > > Speaking of future: in a few days, SourceForge will shut down its CVS > hosting. And as CVS is fading into obsolescence, Python 2 has a few last > years of bugfix-only support left. The python-ldap project now needs > something more than just new development and bug fixes. > > That's where I can help, so I've volunteered to step up as a new > maintainer, provided that we don't find anyone better. > I can't, of course, hope to replace Michael. I don't know that much about > LDAP. My contributions will be mostly limited to the administration side of > things. > > As for my background ? my day job is Python maintenance for Fedora-derived > distros. I've been involved with pyldap, a fork of python-ldap that adds > Python 3 support. > I hope to bring Python 3 support into python-ldap, as that's the mission > that originally brought me to this project. > > > My current plan is: > > # Move to Git > Git is currently the most popular open-source version control system, and > also one I'm familiar with. > The pyldap project has a branch of history imported from CVS, so > conversion should not be a problem. > > # Move to GitHub and Pagure. > GitHub (https://github.com/) is nowadays the most popular Git hosting > provider. Its one big disadvantage is that it's closed-source and > proprietary. > Pagure (https://pagure.io/) is another Git hosting site, which is > open-source. Hopefully that will work for those opposed to GitHub. > (And plain old patch e-mails still work, of course.) > > # Moderate this list > Starting today, I'm a moderator here at python-ldap at python.org. I hope to > keep it a friendly place. > > # Move the documentation to Read the Docs > https://readthedocs.org/ is quite a nice service for hosting Sphinx-based > documentation. Let's put the docs there. > > # Move the website to Read the Docs > If possible, I'll merge the website into the documentation, and point > python-ldap.org there. > If that doesn't work out for any reason, I'll search for another reliable > free-of-charge hosting service for static webpages. > > # Merge changes from the pyldap project > The Python 3 fork was, from the start, intended to be merged back if at > all possible. If I get to maintain python-ldap, that's what will happen. If > possible, I'd like to do it as a series of reviewed changes rather than > import everything wholesale. > > # Continue maintaining > After this I will, as my time allows, merge reviewed code, help with > Python- or Git-related problems, moderate discussions, and generally make > it possible for code authors and reviewers to do their work. > > > If you have any comments or concerns, or would like to help, please speak > up! > > > -- > Petr Viktorin > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > https://mail.python.org/mailman/listinfo/python-ldap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Nov 21 12:04:07 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Nov 2017 18:04:07 +0100 Subject: [python-ldap] Future of python-ldap.org - an introduction, and a plan In-Reply-To: References: <46f51488-2e79-8072-734f-a7a5825e6911@redhat.com> Message-ID: On 11/21/2017 05:47 PM, Carlos Sanchez wrote: > Any plans for pypy/pypy3 support? Not from me, but feel free to contribute that. And if you can get tests to pass under PyPy, let's add it to the testing matrix. > Carlos > > On Tue, Nov 21, 2017 at 9:46 AM, Petr Viktorin > wrote: > > Hello, > As you might have heard, Michael Str?der decided to step down from > maintaining python-ldap. > > Michael, I would like to thank you for the years of maintenance and > development. Python's LDAP story would be nowhere near where it is > now if it weren't for you. > I hope to work together again in the future. > > Speaking of future: in a few days, SourceForge will shut down its > CVS hosting. And as CVS is fading into obsolescence, Python 2 has a > few last years of bugfix-only support left. The python-ldap project > now needs something more than just new development and bug fixes. > > That's where I can help, so I've volunteered to step up as a new > maintainer, provided that we don't find anyone better. > I can't, of course, hope to replace Michael. I don't know that much > about LDAP. My contributions will be mostly limited to the > administration side of things. > > As for my background ? my day job is Python maintenance for > Fedora-derived distros. I've been involved with pyldap, a fork of > python-ldap that adds Python 3 support. > I hope to bring Python 3 support into python-ldap, as that's the > mission that originally brought me to this project. > > > My current plan is: > > # Move to Git > Git is currently the most popular open-source version control > system, and also one I'm familiar with. > The pyldap project has a branch of history imported from CVS, so > conversion should not be a problem. > > # Move to GitHub and Pagure. > GitHub (https://github.com/) is nowadays the most popular Git > hosting provider. Its one big disadvantage is that it's > closed-source and proprietary. > Pagure (https://pagure.io/) is another Git hosting site, which is > open-source. Hopefully that will work for those opposed to GitHub. > (And plain old patch e-mails still work, of course.) > > # Moderate this list > Starting today, I'm a moderator here at python-ldap at python.org > . I hope to keep it a friendly place. > > # Move the documentation to Read the Docs > https://readthedocs.org/ is quite a nice service for hosting > Sphinx-based documentation. Let's put the docs there. > > # Move the website to Read the Docs > If possible, I'll merge the website into the documentation, and > point python-ldap.org there. > If that doesn't work out for any reason, I'll search for another > reliable free-of-charge hosting service for static webpages. > > # Merge changes from the pyldap project > The Python 3 fork was, from the start, intended to be merged back if > at all possible. If I get to maintain python-ldap, that's what will > happen. If possible, I'd like to do it as a series of reviewed > changes rather than import everything wholesale. > > # Continue maintaining > After this I will, as my time allows, merge reviewed code, help with > Python- or Git-related problems, moderate discussions, and generally > make it possible for code authors and reviewers to do their work. > > > If you have any comments or concerns, or would like to help, please > speak up! > > > -- > Petr Viktorin > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > https://mail.python.org/mailman/listinfo/python-ldap > > > -- Petr Viktorin From pviktori at redhat.com Wed Nov 22 05:23:55 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 22 Nov 2017 11:23:55 +0100 Subject: [python-ldap] Version 2.5.2 & code cleanup Message-ID: <6f317785-176c-ce99-6bc8-b6f8faaee879@redhat.com> Hello, As part of python-ldap 2.5.2, the codebase underwent some clean-ups: mainly re-formatting to better comply with PEP 8, the coding style used by most Python projects nowadays. These patches often changed all lines in a file, making it hard to apply patches built on previous versions. And as I said earlier, I'd like to merge Python3 support from pyldap, which is quite a big collection of such patches. To make things easier for me, I'd like to do things in this order: - Start with 2.5.1 - From 2.5.2 (and 2.5.3), cherry-pick only the patches that don't re-format entire files - Merge from pyldap - Re-format files to follow PEP 8 (Python coding guide) and PEP 7 (C coding style) whitespace conventions - Test & release This wouldn't be a direct continuation of 2.5.x, so it needs a minor version, 2.6.0. (Or 3.0, for the symbolism of Python 3 support?) Does that sound OK to everyone? -- Petr Viktorin From christian at python.org Wed Nov 22 05:29:45 2017 From: christian at python.org (Christian Heimes) Date: Wed, 22 Nov 2017 11:29:45 +0100 Subject: [python-ldap] Version 2.5.2 & code cleanup In-Reply-To: <6f317785-176c-ce99-6bc8-b6f8faaee879@redhat.com> References: <6f317785-176c-ce99-6bc8-b6f8faaee879@redhat.com> Message-ID: On 2017-11-22 11:23, Petr Viktorin wrote: > Hello, > > As part of python-ldap 2.5.2, the codebase underwent some clean-ups: > mainly re-formatting to better comply with PEP 8, the coding style used > by most Python projects nowadays. > These patches often changed all lines in a file, making it hard to apply > patches built on previous versions. And as I said earlier, I'd like to > merge Python3 support from pyldap, which is quite a big collection of > such patches. To make things easier for me, I'd like to do things in > this order: > > - Start with 2.5.1 > - From 2.5.2 (and 2.5.3), cherry-pick only the patches that don't > re-format entire files > - Merge from pyldap > - Re-format files to follow PEP 8 (Python coding guide) and PEP 7 (C > coding style) whitespace conventions > - Test & release > > This wouldn't be a direct continuation of 2.5.x, so it needs a minor > version, 2.6.0. (Or 3.0, for the symbolism of Python 3 support?) > > > Does that sound OK to everyone? +1 Full disclosure, I'm a co-maintainer of pyldap fork and work for Red Hat as well. Yesterday I started to rebase pyldap from 2.5.1 to 2.5.2. The code format changes and migration from PyString_Spam() to PyBytes_Spam() caused a lot of merge conflicts. Petr, please also skip the C-API changes for now. Christian From pviktori at redhat.com Fri Nov 24 13:20:42 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 24 Nov 2017 19:20:42 +0100 Subject: [python-ldap] python-ldap development moved to Git Message-ID: <3ece0599-0b75-bae7-3b07-8c1ee4988a77@redhat.com> Hello, The python-ldap project has moved from CVS hosted at SourceForge to Git, hosted at GitHub: https://github.com/python-ldap/python-ldap To get the code, install Git and do: git clone https://github.com/python-ldap/python-ldap The Internet is full of Git tutorials, but if you need some pointers or have a specific problem with Git, let me know! What's in the repository? The "master" branch is based on 2.4.45, with changes from both pyldap (the Python 3 compatibility fork) and python-ldap 2.5.2/2.5.3 merged in. The "2.5" branch contains history imported from CVS. The conversion is pretty good but not perfect. If anyone wants to attempt a better conversion, I have a copy of the SourceForge CVS repository available; just ask. But, GitHub is not open-source! GitHub is quite popular nowadays, but it does run on proprietary software. For folks who prefer to use open-source services, the same code is available at: https://pagure.io/python-ldap What's next? A lot of the infrastructure still needs to be set up. My TODO list is at https://github.com/python-ldap/python-ldap/issues/1 Please let me know if you want to help with something there, to avoid duplicate work. -- Petr Viktorin From carl.nobile at gmail.com Thu Nov 30 11:04:41 2017 From: carl.nobile at gmail.com (Carl Nobile) Date: Thu, 30 Nov 2017 11:04:41 -0500 Subject: [python-ldap] Latest version 2.5.2 does not pip install properly Message-ID: Hi all, I'm trying to install python-ldap-2.5.2 in a virtual environment and I get the error below. Has the `ConfigParser` package been left out of the setup file's `install_requires` argument? Collecting python-ldap (from -r requirements/base.txt (line 34)) Using cached python-ldap-2.5.2.tar.gz Complete output from command python setup.py egg_info: Traceback (most recent call last): File "", line 1, in File "/tmp/pip-build-n7bi9m4s/python-ldap/setup.py", line 9, in from ConfigParser import ConfigParser ImportError: No module named 'ConfigParser' ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-n7bi9m4s/python-ldap/ Thanks, Carl ------------------------------------------------------------------------------- Carl J. Nobile (Software Engineer) carl.nobile at gmail.com ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Nov 30 11:18:20 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 30 Nov 2017 17:18:20 +0100 Subject: [python-ldap] Latest version 2.5.2 does not pip install properly In-Reply-To: References: Message-ID: <7a4bfda7-1926-68ab-8e28-b5ee848b9bcf@redhat.com> On 11/30/2017 05:04 PM, Carl Nobile wrote: > Hi all, > > I'm trying to install python-ldap-2.5.2 in a virtual environment and > I?get the error below. Has the `ConfigParser` package been left out of > the setup file's `install_requires` argument? Hello! The ConfigParser module is part of Python's standard library; it should always be available. Maybe you're trying with Python 3? python-ldap-2.5.2 only supports Python 2.7. (But a python3-compatible version is in the works.) > > Collecting python-ldap (from -r requirements/base.txt (line 34)) > ? Using cached python-ldap-2.5.2.tar.gz > ? ? Complete output from command python setup.py egg_info: > ? ? Traceback (most recent call last): > ? ? ? File "", line 1, in > ? ? ? File "/tmp/pip-build-n7bi9m4s/python-ldap/setup.py", line 9, in > > ? ? ? ? from ConfigParser import ConfigParser > ? ? ImportError: No module named 'ConfigParser' > ? ? ---------------------------------------- > Command "python setup.py egg_info" failed with error code 1 in > /tmp/pip-build-n7bi9m4s/python-ldap/ > -- Petr Viktorin From carl.nobile at gmail.com Thu Nov 30 11:23:57 2017 From: carl.nobile at gmail.com (Carl Nobile) Date: Thu, 30 Nov 2017 11:23:57 -0500 Subject: [python-ldap] Latest version 2.5.2 does not pip install properly In-Reply-To: <7a4bfda7-1926-68ab-8e28-b5ee848b9bcf@redhat.com> References: <7a4bfda7-1926-68ab-8e28-b5ee848b9bcf@redhat.com> Message-ID: Petr, Right, I need to use python 3. It looks like pyldap work fine with python 3, when will that code be merged into python-ldap? Thanks On Thu, Nov 30, 2017 at 11:18 AM, Petr Viktorin wrote: > On 11/30/2017 05:04 PM, Carl Nobile wrote: > >> Hi all, >> >> I'm trying to install python-ldap-2.5.2 in a virtual environment and >> I get the error below. Has the `ConfigParser` package been left out of the >> setup file's `install_requires` argument? >> > > Hello! > The ConfigParser module is part of Python's standard library; it should > always be available. > > Maybe you're trying with Python 3? python-ldap-2.5.2 only supports Python > 2.7. (But a python3-compatible version is in the works.) > > > > >> Collecting python-ldap (from -r requirements/base.txt (line 34)) >> Using cached python-ldap-2.5.2.tar.gz >> Complete output from command python setup.py egg_info: >> Traceback (most recent call last): >> File "", line 1, in >> File "/tmp/pip-build-n7bi9m4s/python-ldap/setup.py", line 9, in >> >> from ConfigParser import ConfigParser >> ImportError: No module named 'ConfigParser' >> ---------------------------------------- >> Command "python setup.py egg_info" failed with error code 1 in >> /tmp/pip-build-n7bi9m4s/python-ldap/ >> >> > -- > Petr Viktorin > -- ------------------------------------------------------------------------------- Carl J. Nobile (Software Engineer) carl.nobile at gmail.com ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.nobile at gmail.com Thu Nov 30 11:30:18 2017 From: carl.nobile at gmail.com (Carl Nobile) Date: Thu, 30 Nov 2017 11:30:18 -0500 Subject: [python-ldap] Latest version 2.5.2 does not pip install properly In-Reply-To: <2ae513b1-705d-06ea-7561-bedad7ee485d@gmail.com> References: <7a4bfda7-1926-68ab-8e28-b5ee848b9bcf@redhat.com> <2ae513b1-705d-06ea-7561-bedad7ee485d@gmail.com> Message-ID: OK, great. Looks like it will be out before our project needs to go to prod next October. (I work for Cisco) I'll continue using pyldap for now then update my requirements file later. Can I rely on the basic usage remaining the same between the two packages? Any major changes that could break code? On Thu, Nov 30, 2017 at 11:26 AM, Petr Viktorin wrote: > On 11/30/2017 05:23 PM, Carl Nobile wrote: > >> Petr, >> >> Right, I need to use python 3. It looks like pyldap work fine with python >> 3, when will that code be merged into python-ldap? >> > > It's merged in the development branch. Expect a beta release next week. > > >> Thanks >> >> >> On Thu, Nov 30, 2017 at 11:18 AM, Petr Viktorin > > wrote: >> >> On 11/30/2017 05:04 PM, Carl Nobile wrote: >> >> Hi all, >> >> I'm trying to install python-ldap-2.5.2 in a virtual environment >> and I get the error below. Has the `ConfigParser` package been >> left out of the setup file's `install_requires` argument? >> >> >> Hello! >> The ConfigParser module is part of Python's standard library; it >> should always be available. >> >> Maybe you're trying with Python 3? python-ldap-2.5.2 only supports >> Python 2.7. (But a python3-compatible version is in the works.) >> >> >> >> >> Collecting python-ldap (from -r requirements/base.txt (line 34)) >> Using cached python-ldap-2.5.2.tar.gz >> Complete output from command python setup.py egg_info: >> Traceback (most recent call last): >> File "", line 1, in >> File "/tmp/pip-build-n7bi9m4s/python-ldap/setup.py", >> line 9, in >> from ConfigParser import ConfigParser >> ImportError: No module named 'ConfigParser' >> ---------------------------------------- >> Command "python setup.py egg_info" failed with error code 1 in >> /tmp/pip-build-n7bi9m4s/python-ldap/ >> >> >> -- Petr Viktorin >> >> >> >> >> -- >> ------------------------------------------------------------ >> ------------------- >> Carl J. Nobile (Software Engineer) >> carl.nobile at gmail.com >> ------------------------------------------------------------ >> ------------------- >> >> >> _______________________________________________ >> python-ldap mailing list >> python-ldap at python.org >> https://mail.python.org/mailman/listinfo/python-ldap >> >> > -- ------------------------------------------------------------------------------- Carl J. Nobile (Software Engineer) carl.nobile at gmail.com ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From encukou at gmail.com Thu Nov 30 11:26:31 2017 From: encukou at gmail.com (Petr Viktorin) Date: Thu, 30 Nov 2017 17:26:31 +0100 Subject: [python-ldap] Latest version 2.5.2 does not pip install properly In-Reply-To: References: <7a4bfda7-1926-68ab-8e28-b5ee848b9bcf@redhat.com> Message-ID: <2ae513b1-705d-06ea-7561-bedad7ee485d@gmail.com> On 11/30/2017 05:23 PM, Carl Nobile wrote: > Petr, > > Right, I need to use python 3. It looks like pyldap work fine with > python 3, when will that code be merged into python-ldap? It's merged in the development branch. Expect a beta release next week. > > Thanks > > On Thu, Nov 30, 2017 at 11:18 AM, Petr Viktorin > wrote: > > On 11/30/2017 05:04 PM, Carl Nobile wrote: > > Hi all, > > I'm trying to install python-ldap-2.5.2 in a virtual environment > and I?get the error below. Has the `ConfigParser` package been > left out of the setup file's `install_requires` argument? > > > Hello! > The ConfigParser module is part of Python's standard library; it > should always be available. > > Maybe you're trying with Python 3? python-ldap-2.5.2 only supports > Python 2.7. (But a python3-compatible version is in the works.) > > > > > Collecting python-ldap (from -r requirements/base.txt (line 34)) > ?? Using cached python-ldap-2.5.2.tar.gz > ?? ? Complete output from command python setup.py egg_info: > ?? ? Traceback (most recent call last): > ?? ? ? File "", line 1, in > ?? ? ? File "/tmp/pip-build-n7bi9m4s/python-ldap/setup.py", > line 9, in > ?? ? ? ? from ConfigParser import ConfigParser > ?? ? ImportError: No module named 'ConfigParser' > ?? ? ---------------------------------------- > Command "python setup.py egg_info" failed with error code 1 in > /tmp/pip-build-n7bi9m4s/python-ldap/ > > > -- > Petr Viktorin > > > > > -- > ------------------------------------------------------------------------------- > Carl J. Nobile (Software Engineer) > carl.nobile at gmail.com > ------------------------------------------------------------------------------- > > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > https://mail.python.org/mailman/listinfo/python-ldap > From pviktori at redhat.com Fri Dec 1 05:52:49 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 1 Dec 2017 11:52:49 +0100 Subject: [python-ldap] Latest version 2.5.2 does not pip install properly In-Reply-To: References: <7a4bfda7-1926-68ab-8e28-b5ee848b9bcf@redhat.com> <2ae513b1-705d-06ea-7561-bedad7ee485d@gmail.com> Message-ID: <0b44fdce-891e-e59e-cfc5-3288be04865a@redhat.com> On 11/30/2017 05:30 PM, Carl Nobile wrote: > OK, great. Looks like it will be out before our project needs to go to > prod next October. (I work for Cisco) > I'll continue using pyldap?for now then update my requirements file later. > Can I rely on the basic usage remaining the same between the two > packages? Any major changes that could break code? Yes, basic usage will remain the same. The big change from python-ldap 2.5.x will be around bytes/text handling. See here: http://python-ldap.readthedocs.io/en/latest/bytes_mode.html If you're updating from pyldap, this should not affect you. > On Thu, Nov 30, 2017 at 11:26 AM, Petr Viktorin > wrote: > > On 11/30/2017 05:23 PM, Carl Nobile wrote: > > Petr, > > Right, I need to use python 3. It looks like pyldap work fine > with python 3, when will that code be merged into python-ldap? > > > It's merged in the development branch. Expect a beta release next week. > > > Thanks > > > On Thu, Nov 30, 2017 at 11:18 AM, Petr Viktorin > > >> wrote: > > ? ? On 11/30/2017 05:04 PM, Carl Nobile wrote: > > ? ? ? ? Hi all, > > ? ? ? ? I'm trying to install python-ldap-2.5.2 in a virtual > environment > ? ? ? ? and I?get the error below. Has the `ConfigParser` > package been > ? ? ? ? left out of the setup file's `install_requires` argument? > > > ? ? Hello! > ? ? The ConfigParser module is part of Python's standard > library; it > ? ? should always be available. > > ? ? Maybe you're trying with Python 3? python-ldap-2.5.2 only > supports > ? ? Python 2.7. (But a python3-compatible version is in the works.) > > > > > ? ? ? ? Collecting python-ldap (from -r requirements/base.txt > (line 34)) > ? ? ? ? ??? Using cached python-ldap-2.5.2.tar.gz > ? ? ? ? ??? ? Complete output from command python setup.py > egg_info: > ? ? ? ? ??? ? Traceback (most recent call last): > ? ? ? ? ??? ? ? File "", line 1, in > ? ? ? ? ??? ? ? File > "/tmp/pip-build-n7bi9m4s/python-ldap/setup.py", > ? ? ? ? line 9, in > ? ? ? ? ??? ? ? ? from ConfigParser import ConfigParser > ? ? ? ? ??? ? ImportError: No module named 'ConfigParser' > ? ? ? ? ??? ? ---------------------------------------- > ? ? ? ? Command "python setup.py egg_info" failed with error > code 1 in > ? ? ? ? /tmp/pip-build-n7bi9m4s/python-ldap/ > > > ? ? --? ? ?Petr Viktorin > > -- Petr Viktorin From pviktori at redhat.com Mon Dec 4 08:39:44 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 4 Dec 2017 14:39:44 +0100 Subject: [python-ldap] ANN: python-ldap 3.0.0b1 (beta release) Message-ID: Find a new BETA release of python-ldap: https://pypi.python.org/pypi/python-ldap/3.0.0b1 This release merges Python 3 support from the pyldap fork, and includes quite a few bug fixes and infrastructure changes. To install this beta release via pip, you need to supply the `--pre` flag: pip install --pre python-ldap A major change relative to python-ldap 2.5.x is bytes/text handling. Read about it here: http://python-ldap.readthedocs.io/en/latest/bytes_mode.html No other breaking changes should be present. Please test with your code and report any issues, either on this mailing list or on the GitHub tracker: https://github.com/python-ldap/python-ldap/issues After years of being hosted by Michael Str?der (thank you!), the project's website was merged with the documentation, and will be hosted at Read the Docs. For a preview of what will be on www.python-ldap.org soon, visit: https://python-ldap.readthedocs.io/ About the project: python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ Git commit hash for the release: python-ldap-3.0.0b1 ed0f6edf0406dbb6824e680c3d8a5a8381f5f0bb ---------------------------------------------------------------- Released 3.0.0b1 2017-12-04 Changes since 2.4.45: (this list includes changes from 2.5.x) New dependencies (automatically installed when using pip): * pyasn1 0.3.7+ * pyasn1_modules 0.1.5+ Python 3 support and bytes_mode: * merged from the pyldap fork (https://github.com/pyldap) * please see documentation on bytes_mode and text/bytes handling: https://python-ldap.readthedocs.io/en/latest/bytes_mode.html Removed support for Python 2.6. Infrastructure: * Move to Git * Don't define search path for includes and libs in the default setup.cfg * Include sasl/sasl.h from the standard path * Re-format README to ReStructured Text * Setup for automatic testing using Travis CI * Add coverage reporting for Python and C * Add install requires into setup.py * Remove distclean.sh in favor of make clean * Use `package`, `depends`, `install_requires` in setup.py * Add make target for scan-build (static analysis using clang) Modules/ * Remove unused LDAPberval helper functions * Fix type conversion in page control * Fix multiple ref leaks in error-handling code * Fix reference leak in result4 * Fix several compiler warnings * Fix memory leak in whoami * Fix internal error handling of LDAPControl_to_List() * Fix two memory leaks and release GIL in encode_assertion_control * Allow set_option() to set timeouts to infinity and, thanks to Michael Str?der: * removed unused code schema.c * moved code from version.c to ldapmodule.c * removed obsolete back-ward compability constants from common.h * build checks whether LDAP_API_VERSION is OpenLDAP 2.4.x * _ldap.__author__ and _ldap.__license__ also set from ldap.pkginfo * assume C extension API for Python 2.7+ Lib/ * Avoid eval() for getting module-level variables to fix running under pytest * Compability changes for pyasn1 0.3 or newer and, thanks to Michael Str?der: * ldap.__version__, ldap.__author__ and ldap.__license__ now imported from new sub-module ldap.pkginfo also to setup.py * Added safety assertion when importing _ldap: ldap.pkginfo.__version__ must match _ldap.__version__ * removed stand-alone module dsml * slapdtest.SlapdObject.restart() just restarts slapd without cleaning any data * The methods SSSResponseControl.decodeControlValue() and VLVResponseControl.decodeControlValue() now follow the coding convention to use camel-cased ASN.1 name as class attribute name. The old class names are still set for back-ward compability but should not be used in new code because they might be removed in a later release. * removed SSSRequestControl from ldap.controls.KNOWN_RESPONSE_CONTROLS * removed all dependencies on modules string and types * removed use of .has_key() * removed class ldap.ldapobject.NonblockingLDAPObject * new global constant ldap.LIBLDAP_API_INFO * right after importing _ldap there is a call into libldap to initialize it * method .decodeControlValue() of SSSResponseControl and VLVResponseControl does not set class attribute result_code anymore * always use bytes() for UUID() constructor in ldap.syncrepl * module ldif now uses functions b64encode() and b64decode() * fixed pickling and restoring of ReconnectLDAPObject Lib/slapdtest * Automatically try some common locations for SCHEMADIR * Ensure server is stopped when the process exits * Check for LDAP schema and slapd binaries * slapdtest is now a package and includes testing certificates Tests/ * Expand cidict membership test * Add test suite for binds * Add test suite for edits * Add a smoke-check for listall() and attribute_types() * Add test case for SASL EXTERNAL auth * Add tests for start_tls * In CI, treat compiler warnings as fatal errors * Added tests for ldap.syncrepl and, thanks to Michael Str?der: * added explicit reconnect tests for ReconnectLDAPObject * scripts do not directly call SlapdTestCase.setUpClass() anymore * added LDIF test with folded, base64-encoded attribute * added more tests for sub-module ldap.dn Doc/ * Build documentation without the compiled C extension * Merge contents from python-ldap.org * Move reference documentation in its own section * Document return value of {modify,add,delete}_ext_s() as a tuple * Add tests for documentation (build & spelling) * Link to documentation of old versions * Add a contributing guide -- Petr Viktorin From samadhan.madane at gslab.com Tue Dec 5 07:48:09 2017 From: samadhan.madane at gslab.com (Samadhan Madane) Date: Tue, 5 Dec 2017 18:18:09 +0530 Subject: [python-ldap] pyldap : Windows Installation Issue Message-ID: I am getting an error when I try install (e.g. pip install pyldap) on windows7(64bit), python 3.6.3 . The error is: c:\users\appdata\local\temp\pip-build-mek8zven\pyldap\modules\errors.h(8): fatal error C1083: Cannot open include file: 'lber.h': No such file or directory error: command 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe' failed with exit status 2 >From what I can tell, I believe this is related to an openldap library but I do not know how to resolve. Any help would be very much appreciated. Thanks. -- *Thanks & Regards,* Samadhan Madane Software Engineer | 7058183104 G reat Software Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: From waldemar.osuch at gmail.com Tue Dec 5 14:02:53 2017 From: waldemar.osuch at gmail.com (Waldemar Osuch) Date: Tue, 05 Dec 2017 19:02:53 +0000 Subject: [python-ldap] pyldap : Windows Installation Issue In-Reply-To: References: Message-ID: Hi, Instead of building it yourself the simplest solution is to visit Christoph Gohlke awesome site https://www.lfd.uci.edu/~gohlke/pythonlibs/ And download the pre-built wheels from there. Thank you, Waldemar On Tue, Dec 5, 2017 at 6:05 AM Samadhan Madane wrote: > I am getting an error when I try install (e.g. pip install pyldap) on > windows7(64bit), python 3.6.3 . The error is: > > c:\users\appdata\local\temp\pip-build-mek8zven\pyldap\modules\errors.h(8): > fatal error C1083: Cannot open include file: 'lber.h': No such file or > directory > error: command 'C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\BIN\cl.exe' failed with exit status 2 > > From what I can tell, I believe this is related to an openldap library but > I do not know how to resolve. > > Any help would be very much appreciated. Thanks. > > -- > *Thanks & Regards,* > Samadhan Madane > Software Engineer | 7058183104 <(705)%20818-3104> > G reat Software > Laboratory > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > https://mail.python.org/mailman/listinfo/python-ldap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Dec 11 10:47:11 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 11 Dec 2017 16:47:11 +0100 Subject: [python-ldap] ANN: python-ldap 3.0.0b2 (beta release) Message-ID: Find a new BETA release of python-ldap: https://pypi.python.org/pypi/python-ldap/3.0.0b2 To install this beta release via pip, you need to supply the `--pre` flag: pip install --pre python-ldap Please test with your code and report any issues, either on this mailing list or on the GitHub tracker: https://github.com/python-ldap/python-ldap/issues There is currently one issue I'd like to fix before going out of beta. An up-to-date list is at: https://github.com/python-ldap/python-ldap/milestone/1 About the project: python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ After years of being hosted by Michael Str?der (thank you!), the project's website was merged with the documentation, and is hosted at Read the Docs & Cloudflare. Git commit hash for the release: python-ldap-3.0.0b2 673957dfcbf3769778c184db296ad601e669c70d ---------------------------------------------------------------- Released 3.0.0b2 2017-12-11 Changes since 3.0.0b1: The module `ldap.async` is renamed to `ldap.asyncsearch`, due to `async` becoming a keyword in Python 3.7. The old module name is deprecated, but will be available as long as Python 3.6 is supported. Lib/ * Use custom ldap.LDAPBytesWarning class * Rename ldap.async to ldap.asyncsearch Modules/ * Support None for set_option(OPT_TIMEOUT) and OPT_NETWORK_TIMEOUT * Fix error reporting of LDAPObject.set_option() * Change memory handling in attrs_from_List() Test/ * Remove workaround for OpenLDAP NSS issue Demo/ * Use uniform shebang in all demos Doc/ * Provide build deps for Alpine and CentOS * Move sample workflow out of the main Contributing guide Infrastructure: * Add valgrind target to check for memory leaks * Minimal configuration for pytest -- Petr Viktorin From yasmeen.hesham at positiveedge-mea.com Thu Dec 14 07:19:05 2017 From: yasmeen.hesham at positiveedge-mea.com (yasmeen hesham) Date: Thu, 14 Dec 2017 14:19:05 +0200 Subject: [python-ldap] Idap installation on windows 10 Message-ID: <3yyCYG0VvczFqss@mail.python.org> Dear sir I wanna installing pyldap?on windows 10 , and it is ceased an error . Is there any help? Thanks, Yasmeen Hesham -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at python.org Thu Dec 14 08:27:11 2017 From: christian at python.org (Christian Heimes) Date: Thu, 14 Dec 2017 14:27:11 +0100 Subject: [python-ldap] Idap installation on windows 10 In-Reply-To: <3yyCYG0VvczFqss@mail.python.org> References: <3yyCYG0VvczFqss@mail.python.org> Message-ID: On 2017-12-14 13:19, yasmeen hesham wrote: > Dear sir > > ????I wanna installing pyldap?on windows 10 , and it is ceased an error . > > Is there any help? We don't provide Windows binaries because it's really, really complicated to build all dependencies on Windows. Christoph Gohlke provides unofficial Windows binaries. https://python-ldap.readthedocs.io/en/latest/faq.html#installing https://python-ldap.readthedocs.io/en/latest/installing.html#windows HTH, Christian From pviktori at redhat.com Tue Dec 19 04:39:25 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 19 Dec 2017 10:39:25 +0100 Subject: [python-ldap] python-ldap.org is temporarily down Message-ID: <310fd0df-585a-d4d1-7299-32cb3075f645@redhat.com> Hello, Unfortunately, python-ldap.org is now down due to problems with domain registration. I'm working with Michael to resolve this, but it might take some time. In the mean time, the content is available at https://python-ldap.readthedocs.io/ I'm very sorry for the inconvenience. -- Petr Viktorin From pviktori at redhat.com Wed Dec 20 10:14:25 2017 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 20 Dec 2017 16:14:25 +0100 Subject: [python-ldap] ANN: python-ldap 3.0.0b3 (beta release) Message-ID: Find a new BETA release of python-ldap: https://pypi.python.org/pypi/python-ldap/3.0.0b3 To install this beta release via pip, you need to supply the `--pre` flag: pip install --pre python-ldap Please test with your code and report any issues, either on this mailing list or on the GitHub tracker: https://github.com/python-ldap/python-ldap/issues If there are no major issues found with it, this will become 3.0.0 in the beginning of the year. About the project: python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ After years of being hosted by Michael Str?der (thank you!), the project's website was merged with the documentation, and is hosted at Read the Docs & Cloudflare. Git commit hash for the release: python-ldap-3.0.0b3 7846ba138e89c7cc6b4a8cee57fd1409273022e3 ---------------------------------------------------------------- Released 3.0.0b3 2017-12-20 Changes since 3.0.0b2: The functions `ldap.open()`, `ldap.init()`, `ldif.CreateLDIF()` and `ldif.ParseLDIF()`, which were deprecated for over a decade, are scheduled for removal in python-ldap 3.1. Infrastructure: * Require setuptools to build * Start running automatic tests on PyPy Lib/ * When raising LDAPBytesWarning, give helpful code locations * Use modern Python idioms in several places * Avoid reimplementing UserDict.get() in cidict and models.Entry Doc/ * Use https links Test/ * Add reproducer for openldap's NSS shutdown/restart issue * Make testing on non-Linux platforms easier -- Petr Viktorin From Matt.Fahrner at burlingtonstores.com Wed Dec 20 14:16:11 2017 From: Matt.Fahrner at burlingtonstores.com (Matt Fahrner) Date: Wed, 20 Dec 2017 19:16:11 +0000 Subject: [python-ldap] Quick question - can use use ldap.resiter with paged controls? Message-ID: <6B9F9E8F-83B1-4D38-9DCB-D02E166D3B4B@burlingtonstores.com> I actually don?t need this for my current project, but I wondered as it is a likely combination to need paged controls with a large query like would be used with ?ldap.resiter?. Thanks in advance! - Matt Matt Fahrner Enterprise Architect Burlington Stores, Inc. ________________________________ Notice: This communication, including attachments, may contain confidential or proprietary information to be conveyed solely for the intended recipient(s). If you are not the intended recipient, or if you otherwise received this message in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments, without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: