From encukou at gmail.com  Mon Jan  3 07:24:59 2022
From: encukou at gmail.com (Petr Viktorin)
Date: Mon, 3 Jan 2022 13:24:59 +0100
Subject: [python-ldap] New maintainers
Message-ID: <b6480f6d-fb49-4044-94ec-d34f20f54681@gmail.com>

I've given repo admin permissions to:

- @mistotebe (Ond?ej Kuzn?k)
- @droideck (Simon Pichugin)

I hope things will be faster with more people on board :)

Thanks for volunteering to carry the torch! The future of python-ldap is 
now in your hands.
But I suggest you go for gentle evolution: if a completely new set of 
APIs is added, it would be better as a separate project, either on top 
of or alongside python-ldap, without unnecessary baggage.



Oh, and please send me your usernames on the other services so I can add 
you there as well:
- pypi.org
- readthedocs.org

From ondra at mistotebe.net  Tue Jan  4 07:03:57 2022
From: ondra at mistotebe.net (=?utf-8?B?T25kxZllaiBLdXpuw61r?=)
Date: Tue, 4 Jan 2022 13:03:57 +0100
Subject: [python-ldap] ldap.REFERRAL exception only returns first
 referral
In-Reply-To: <CAJnExnM50Wd1iuZEiaEwA5RzH5k_E6aWhW7Qju5JSGat_CFXjw@mail.gmail.com>
References: <CAJnExnPVpkZ=5jGQPfWYpema-MWBsmbFbfXsXrqAATrHVtvRFQ@mail.gmail.com>
 <CAJnExnM50Wd1iuZEiaEwA5RzH5k_E6aWhW7Qju5JSGat_CFXjw@mail.gmail.com>
Message-ID: <20220104120357.GR6219@mistotebe.net>

On Thu, Dec 16, 2021 at 08:51:04PM -0500, Nick Folino wrote:
> I found the code that passes the first referral only (Modules/constants.c).
> Was this done for a specific reason?
> Are there any developers still on the project that are familiar with that
> code?
> I don't mind helping to maintain this project, but it'll take me a
> while to get up to speed on the code.

Hi Nick,
thanks for the report, you're right, the referral isn't being passed
properly. We should really pass all the references as a list in a new
field there, not just a string message in 'info'.

If you (or anyone else) want to prepare that change, submit a PR and
I'll happily review it. Otherwise it might have to wait until I've
decided how to fix some other issues I have with the way we do
exceptions right now.

Regards,
Ondrej

From chris.paul at rexconsulting.net  Tue Jan 25 20:10:49 2022
From: chris.paul at rexconsulting.net (Christopher Paul)
Date: Tue, 25 Jan 2022 17:10:49 -0800
Subject: [python-ldap] ldap.AUTH_UNKNOWN: {'result': -6,
 'desc': 'Unknown authentication method', 'ctrls': [],
 'info': 'SASL(-4): no mechanism available: '}
Message-ID: <280d5ec6-ae50-ca53-ea95-7462a685c0aa@rexconsulting.net>

Hello python-ldap users,

What am I doing wrong? The same settings work in an "$HOME/.ldaprc" file.

$ python3
Python 3.6.8 (default, Sep 10 2021, 09:13:53)
[GCC 8.5.0 20210514 (Red Hat 8.5.0-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
 >>> import ldap
 >>> ldap.__version__
'3.3.1'
 >>> import ldap.sasl
 >>> conn = ldap.initialize ("ldap://ldap.lab.local")
 >>> conn.set_option(ldap.OPT_X_TLS_CERTFILE, '/home/fuu/.tls/cert.pem')
 >>> conn.set_option(ldap.OPT_X_TLS_KEYFILE, '/home/fuu/.tls/key.pem')
 >>> conn.set_option(ldap.OPT_X_TLS_CACERTDIR, '/etc/openldap/tls/cacerts/')
 >>> conn.sasl_external_bind_s()
Traceback (most recent call last):
 ? File "<stdin>", line 1, in <module>
 ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 
492, in sasl_external_bind_s
self.sasl_non_interactive_bind_s('EXTERNAL',serverctrls,clientctrls,sasl_flags,authz_id)
 ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 
486, in sasl_non_interactive_bind_s
self.sasl_interactive_bind_s('',auth,serverctrls,clientctrls,sasl_flags)
 ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 
476, in sasl_interactive_bind_s
 ??? return 
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
 ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 
340, in _ldap_call
 ??? reraise(exc_type, exc_value, exc_traceback)
 ? File "/usr/lib64/python3.6/site-packages/ldap/compat.py", line 46, in 
reraise
 ??? raise exc_value
 ? File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 
324, in _ldap_call
 ??? result = func(*args,**kwargs)
ldap.AUTH_UNKNOWN: {'result': -6, 'desc': 'Unknown authentication 
method', 'ctrls': [], 'info': 'SASL(-4): no mechanism available: '}

thanks,

Chris Paul
Rex Consulting, Inc
email: chris.paul at rexconsulting.net
web: http://www.rexconsulting.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/python-ldap/attachments/20220125/bda85551/attachment.html>

From ondra at mistotebe.net  Wed Jan 26 05:44:40 2022
From: ondra at mistotebe.net (=?utf-8?B?T25kxZllaiBLdXpuw61r?=)
Date: Wed, 26 Jan 2022 11:44:40 +0100
Subject: [python-ldap] ldap.AUTH_UNKNOWN: {'result': -6,
 'desc': 'Unknown authentication method', 'ctrls': [],
 'info': 'SASL(-4): no mechanism available: '}
In-Reply-To: <280d5ec6-ae50-ca53-ea95-7462a685c0aa@rexconsulting.net>
References: <280d5ec6-ae50-ca53-ea95-7462a685c0aa@rexconsulting.net>
Message-ID: <20220126104440.GF26609@mistotebe.net>

On Tue, Jan 25, 2022 at 05:10:49PM -0800, Christopher Paul wrote:
> Hello python-ldap users,
> 
> What am I doing wrong? The same settings work in an "$HOME/.ldaprc" file.

Hi Chris,
I assume you need to apply the TLS options first:
https://www.python-ldap.org/en/python-ldap-3.3.0/reference/ldap.html#tls-options

Regards,

-- 
Ond?ej Kuzn?k
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP

From chris.paul at rexconsulting.net  Wed Jan 26 12:43:51 2022
From: chris.paul at rexconsulting.net (Christopher Paul)
Date: Wed, 26 Jan 2022 09:43:51 -0800
Subject: [python-ldap] ldap.AUTH_UNKNOWN: {'result': -6,
 'desc': 'Unknown authentication method', 'ctrls': [],
 'info': 'SASL(-4): no mechanism available: '}
In-Reply-To: <20220126104440.GF26609@mistotebe.net>
References: <280d5ec6-ae50-ca53-ea95-7462a685c0aa@rexconsulting.net>
 <20220126104440.GF26609@mistotebe.net>
Message-ID: <c9dead16-8b1e-984e-6f79-373126652914@rexconsulting.net>

On 1/26/2022 2:44 AM, Ond?ej Kuzn?k wrote:
> ...

Thanks Ond?ej!

And Bingo, that was it! Specifically I had to 
set_option(ldap.OPT_X_TLS_NEWCTX, 0) after setting the TLS options in 
order to apply the settings.

Future People, note the docs I had been missing until now are 
https://github.com/python-ldap/python-ldap/blob/master/Doc/reference/ldap.rst. 
See the Warning section until "TLS options".

Chris Paul
Rex Consulting, Inc
email: chris.paul at rexconsulting.net
web: http://www.rexconsulting.net




From philipp_s_p_developer at web.de  Sun Jan 30 17:27:33 2022
From: philipp_s_p_developer at web.de (philipp_s_p_developer at web.de)
Date: Sun, 30 Jan 2022 23:27:33 +0100
Subject: [python-ldap] Question - Usage of windows certificate store for
 certificate check in TLS handshake
Message-ID: <trinity-4baf2f11-1aca-4a7c-bff7-f628928ede49-1643581653916@3c-app-webde-bs04>

An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/python-ldap/attachments/20220130/6f86defc/attachment.html>

From william at blackhats.net.au  Mon Jan 31 18:09:30 2022
From: william at blackhats.net.au (William Brown)
Date: Tue, 1 Feb 2022 09:09:30 +1000
Subject: [python-ldap] Question - Usage of windows certificate store for
 certificate check in TLS handshake
In-Reply-To: <trinity-4baf2f11-1aca-4a7c-bff7-f628928ede49-1643581653916@3c-app-webde-bs04>
References: <trinity-4baf2f11-1aca-4a7c-bff7-f628928ede49-1643581653916@3c-app-webde-bs04>
Message-ID: <65DA6C59-BBCE-4433-9BBE-C19CD19D2CDA@blackhats.net.au>



> On 31 Jan 2022, at 08:27, philipp_s_p_developer at web.de wrote:
> 
> Hello,
> 
> our objective is to connect to a domain server using LDAPS. We want to perform the TLS handshake including the step to verify the server certificate.
> 
> We have performed tests using different setups in terms of certificate chains. We used the TLS options to set OPT_X_TLS_REQUIRE_CERT to OPT_X_TLS_DEMAND. Our client runs on a Windows operating system and OpenSSL is used as the backend implementation for TLS. To provide the certificate information that is required for the validation of the server certificate, we have performed tests with both options, a PEM file and OPT_X_TLS_CACERTFILE as well as a directory of certificate files and OPT_X_TLS_CACERTDIR. Both worked as expected.
> 
> However, so far we have failed to perform the server certificate validation using trusted certificates that are located in the Certificate Stores of Windows.
> 
> Is it possible to use the Windows Certificate Stores for server certificate validation using python-ldap?
> 
> In case it is possible, what must be done to configure python-ldap accordingly?

The way that python-ldap works is that it links to and uses openldap's client libraries to actually do the network connections. That means it "depends" on how openldap client libs were installed on your system. 

It appears that it may be possible for OpenSSL to use the windows CA store, but that would require extra code to be present in the openldap code that may or may not be present.

So I would "assume" for you that it's unlikely this has been done, so you'll need to provide your CA certs in PEM format. 

Hope that helps, 



> 
> I would appreciate your help.
> 
> Best regards,
> 
> Philipp Sp.
> 
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap

--
Sincerely,

William


From chris.paul at rexconsulting.net  Tue Mar 15 01:05:09 2022
From: chris.paul at rexconsulting.net (Christopher Paul)
Date: Tue, 15 Mar 2022 05:05:09 +0000
Subject: [python-ldap] looking for example of using ManageDSA control
Message-ID: <DM6PR12MB4974B0FFFB04AEFABBD040C29D109@DM6PR12MB4974.namprd12.prod.outlook.com>

Hello python-ldap users,

I am wondering if anyone could show an example of an ldap search using python-ldap with the manage DSA IT control. I'm missing something from reading the docs. I'm just not sure what to put after "serverctls=".

Many thanks,

Chris Paul | Rex Consulting | https://www.rexconsulting.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/python-ldap/attachments/20220315/386e816a/attachment.html>

From ondra at mistotebe.net  Tue Mar 15 06:26:12 2022
From: ondra at mistotebe.net (=?utf-8?B?T25kxZllaiBLdXpuw61r?=)
Date: Tue, 15 Mar 2022 11:26:12 +0100
Subject: [python-ldap] Supporting syncrepl (and fixing LDAPObject.results{, 2,
 3, 4})
Message-ID: <20220315102612.GW26609@mistotebe.net>

Hi all,
this has been on my list for a while and definitely needs fixing
for 4.0. The way we parse results is broken, we cannot process
intermediate responses properly and the results are n-tuples where n
often depends on the arguments passed to .result4(). Also the way
LDAPmessage_to_python works, we lose the order messages actually came
in, that's a no-no for syncrepl at the very least. And .result() callers
shouldn't get an exception when a non-zero result message is received,
losing all other messages in the process forever.

This needs work on all levels of the module:
- C code needs to expose a new results interface that returns everything
  in a common interface with common fields like result, message,
  references, OID, controls etc. where appropriate.
- by the time they are returned from the Python side, each response should
  be an instance of LDAPMessage subclass as appropriate with controls,
  intermediate and extended messages fully decoded if a decoder is
  available. It will be possible to check the result code and raise an
  appropriate exception as usual for each message derived from
  LDAPResult.

This is a stepping stone towards a similar overhaul of the request API,
removing some of the distinction between the _s and non-_s variants as
well as resiter eventually enabling asyncio compatible operation (see
my asyncio wrapper[0] for an example how the API could look like).
Of course, it will be fun to make sure we don't break any backwards
compatibility in the 3.x interface for others.

Comments on the design and volunteers to help with this are welcome.

[0]. https://git.openldap.org/openldap/syncmonitor/-/blob/master/syncmonitor/ldap_wrapper.py

Regards,

-- 
Ond?ej Kuzn?k
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP

From ondra at mistotebe.net  Tue Mar 15 07:21:55 2022
From: ondra at mistotebe.net (=?utf-8?B?T25kxZllaiBLdXpuw61r?=)
Date: Tue, 15 Mar 2022 12:21:55 +0100
Subject: [python-ldap] looking for example of using ManageDSA control
In-Reply-To: <DM6PR12MB4974B0FFFB04AEFABBD040C29D109@DM6PR12MB4974.namprd12.prod.outlook.com>
References: <DM6PR12MB4974B0FFFB04AEFABBD040C29D109@DM6PR12MB4974.namprd12.prod.outlook.com>
Message-ID: <20220315112155.GX26609@mistotebe.net>

On Tue, Mar 15, 2022 at 05:05:09AM +0000, Christopher Paul wrote:
> Hello python-ldap users,
> 
> I am wondering if anyone could show an example of an ldap search using
> python-ldap with the manage DSA IT control. I'm missing something from
> reading the docs. I'm just not sure what to put after "serverctls=".

Hi Chris,
as mentioned in the documentation[0], you pass a list of control
instances in serverctrls. Something like this:

manage_control = ldap.controls.simple.ManageDSAITControl(criticality)
search_ext_s(..., serverctrls=[manage_control])

[0]. https://www.python-ldap.org/en/python-ldap-3.3.0/reference/ldap.html#arguments-for-ldapv3-controls

Regards,

> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap


From pviktori at redhat.com  Tue Mar 15 12:20:43 2022
From: pviktori at redhat.com (Petr Viktorin)
Date: Tue, 15 Mar 2022 17:20:43 +0100
Subject: [python-ldap] Supporting syncrepl (and fixing
 LDAPObject.results{, 2, 3, 4})
In-Reply-To: <20220315102612.GW26609@mistotebe.net>
References: <20220315102612.GW26609@mistotebe.net>
Message-ID: <2ff54cd3-578b-a5ec-686e-5f90a13812f2@redhat.com>

On 15. 03. 22 11:26, Ond?ej Kuzn?k wrote:
> Hi all,
> this has been on my list for a while and definitely needs fixing
> for 4.0. The way we parse results is broken, we cannot process
> intermediate responses properly and the results are n-tuples where n
> often depends on the arguments passed to .result4(). Also the way
> LDAPmessage_to_python works, we lose the order messages actually came
> in, that's a no-no for syncrepl at the very least. And .result() callers
> shouldn't get an exception when a non-zero result message is received,
> losing all other messages in the process forever.
> 
> This needs work on all levels of the module:
> - C code needs to expose a new results interface that returns everything
>    in a common interface with common fields like result, message,
>    references, OID, controls etc. where appropriate.
> - by the time they are returned from the Python side, each response should
>    be an instance of LDAPMessage subclass as appropriate with controls,
>    intermediate and extended messages fully decoded if a decoder is
>    available. It will be possible to check the result code and raise an
>    appropriate exception as usual for each message derived from
>    LDAPResult.
> 
> This is a stepping stone towards a similar overhaul of the request API,
> removing some of the distinction between the _s and non-_s variants as
> well as resiter eventually enabling asyncio compatible operation (see
> my asyncio wrapper[0] for an example how the API could look like).
> Of course, it will be fun to make sure we don't break any backwards
> compatibility in the 3.x interface for others.
> 
> Comments on the design and volunteers to help with this are welcome.

FWIW, the general way to upgrade from tuples to objects with attributes 
in C is PyStructSequence [1], the implementation of os.stat_result or 
sys.float_info. Unlike a Python namedtuple, it allows named-only 
attributes. So the result() return value could continue to be a 
backwards-compatible 2-tuple but have all other relevant attributes as well.


> [0]. https://git.openldap.org/openldap/syncmonitor/-/blob/master/syncmonitor/ldap_wrapper.py
[1] https://docs.python.org/3/c-api/tuple.html#c.PyStructSequence_NewType


From ondra at mistotebe.net  Wed Mar 16 07:15:36 2022
From: ondra at mistotebe.net (=?utf-8?B?T25kxZllaiBLdXpuw61r?=)
Date: Wed, 16 Mar 2022 12:15:36 +0100
Subject: [python-ldap] Supporting syncrepl (and fixing
 LDAPObject.results{, 2, 3, 4})
In-Reply-To: <2ff54cd3-578b-a5ec-686e-5f90a13812f2@redhat.com>
References: <20220315102612.GW26609@mistotebe.net>
 <2ff54cd3-578b-a5ec-686e-5f90a13812f2@redhat.com>
Message-ID: <20220316111536.GA26609@mistotebe.net>

On Tue, Mar 15, 2022 at 05:20:43PM +0100, Petr Viktorin wrote:
> FWIW, the general way to upgrade from tuples to objects with attributes in C
> is PyStructSequence [1], the implementation of os.stat_result or
> sys.float_info. Unlike a Python namedtuple, it allows named-only attributes.
> So the result() return value could continue to be a backwards-compatible
> 2-tuple but have all other relevant attributes as well.

Thanks, that is a really useful tip, I'll keep that in mind since it's
going to come up again. The change in exception behaviour can't be done
in results4 so I think we need a new endpoint anyway. On the other hand
it makes it really tempting to adopt this approach too if migrating from
old results API to the new one is made substantially smoother.

Regards,

-- 
Ond?ej Kuzn?k
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP

From stephen.butler at gmail.com  Wed Mar 16 15:08:37 2022
From: stephen.butler at gmail.com (Stephen J. Butler)
Date: Wed, 16 Mar 2022 14:08:37 -0500
Subject: [python-ldap] Supporting syncrepl (and fixing
 LDAPObject.results{, 2, 3, 4})
In-Reply-To: <20220315102612.GW26609@mistotebe.net>
References: <20220315102612.GW26609@mistotebe.net>
Message-ID: <CAD4ANxUF_J-uYv0SKxqf+mNEgOiSRM7HiZ_dWBdYf=rFWpwjeQ@mail.gmail.com>

Apologies, my memory is fuzzy on this...

Way back in 2015 I was working with the result2() function and trying to
handle a case where I'd performed multiple LDAP operations at once (in this
case, I'd start a search over multiple bases at the same time and use the
result2() function to process them as they came in). My issue at the time
was that I could catch the LDAPError thrown from result2(), but the error
object did not contain the msgid that caused the error. So I didn't know if
it was one of my parallel searches that errored, or some extended operation
with an immediate result, or something else in the code. I submitted a
patch but there was some discussion and IDK that LDAPError ever got a msgid
field.

As I'm reading your proposal it sounds like this new result handling would
not throw an LDAPError for non-zero and let the calling code handle it. If
I'd had that back in 2015 I think that would have solved my issue. So ?



On Tue, Mar 15, 2022 at 7:10 AM Ond?ej Kuzn?k <ondra at mistotebe.net> wrote:

> Hi all,
> this has been on my list for a while and definitely needs fixing
> for 4.0. The way we parse results is broken, we cannot process
> intermediate responses properly and the results are n-tuples where n
> often depends on the arguments passed to .result4(). Also the way
> LDAPmessage_to_python works, we lose the order messages actually came
> in, that's a no-no for syncrepl at the very least. And .result() callers
> shouldn't get an exception when a non-zero result message is received,
> losing all other messages in the process forever.
>
> This needs work on all levels of the module:
> - C code needs to expose a new results interface that returns everything
>   in a common interface with common fields like result, message,
>   references, OID, controls etc. where appropriate.
> - by the time they are returned from the Python side, each response should
>   be an instance of LDAPMessage subclass as appropriate with controls,
>   intermediate and extended messages fully decoded if a decoder is
>   available. It will be possible to check the result code and raise an
>   appropriate exception as usual for each message derived from
>   LDAPResult.
>
> This is a stepping stone towards a similar overhaul of the request API,
> removing some of the distinction between the _s and non-_s variants as
> well as resiter eventually enabling asyncio compatible operation (see
> my asyncio wrapper[0] for an example how the API could look like).
> Of course, it will be fun to make sure we don't break any backwards
> compatibility in the 3.x interface for others.
>
> Comments on the design and volunteers to help with this are welcome.
>
> [0].
> https://git.openldap.org/openldap/syncmonitor/-/blob/master/syncmonitor/ldap_wrapper.py
>
> Regards,
>
> --
> Ond?ej Kuzn?k
> Senior Software Engineer
> Symas Corporation                       http://www.symas.com
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP
> _______________________________________________
> 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: <https://mail.python.org/pipermail/python-ldap/attachments/20220316/ce85c0cb/attachment.html>