Easy workaround that can be used before it’s fixed properly:

--- a/setup.cfg
+++ b/setup.cfg
@@ -23,7 +23,7 @@
 
 # Example for full-featured build:
 # Support for StartTLS/LDAPS, SASL bind and reentrant libldap_r.
-libs = ldap_r lber
+libs = ldap lber
 
 # Installation options
 [install]

Unfortunately 2.5 support is not trivial. Your PR would cause issues for 2.4 builds. In 2.4 we always want to build against the re-entrant version of libldap.

All our major target platforms have OpenLDAP 2.4. We have to keep support for 2.4 until Debian 11 (just released a couple of months ago) and RHEL 9 (current under development) have reached their end of lifetime. AFAIK non of our CI platforms have OpenLDAP 2.5 yet. We have no means to verify and check any 2.5 related changes.

Your PR would cause issues for 2.4 builds.

It’s not a PR, it’s just a quick workaround for other distro package maintainers who encounter the same problem. I don’t understand how “Easy workaround that can be used before it’s fixed properly” could be misunderstood.

AFAIK non of our CI platforms have OpenLDAP 2.5 yet. We have no means to verify and check any 2.5 related changes.

You can add a new CI job that will build OpenLDAP from sources and test against it. Since this project provides bindings for libldap, you should already be running regression tests against a matrix of the supported OpenLDAP versions.

Or you can wait until Alpine Linux v3.15 is released (in couple of weeks max) and use it for testing OpenLDAP 2.6 – you can use it on GitHub Actions via jobs.<job_id>.container.image or alpine-chroot-install (example of usage on GitHub Actions).

@jirutka - It's also not a valid workaround. Please don't advertise it as such. This issue needs proper attention and time so that we don't break user's applications.

It's also not a valid workaround.

Can you please elaborate why it’s not a valid workaround? All tests pass (after fixing two unrelated bugs in tests).

The correct solution would be to test if libldap is re-entrant. If it is, then link to it. If it is not, then see if libldap_r is available, and link to it if it is. Otherwise fail. It's possible to build libldap in 2.5 and 2.6 so that it is not re-entrant, although that's not expected to be a common case.

I know that it’s not a correct solution and never said it was.
I very clearly said: “it’s just a quick workaround for other distro package maintainers”. What you don’t understand on this sentence?

It’s safe to assume that libldap is built as re-entrant when I control how it’s built. I had only two options: apply this workaround, or drop the pyldap package from the distribution. Holding OpenLDAP upgrade because of one insignificant package was not an option.

I think I see where the misunderstanding is coming from.

Easy workaround that can be used before it’s fixed properly

You probably took that as a workaround that can be applied by you as the upstream, i.e. merged into this repository. I never meant it in this way. If I did, I would open a pull request. However, I clarified this in the next comment.

It was always clear to me that you were providing a workaround. My comment was for @tiran on how to correctly fix python-ldap to work with both OpenLDAP 2.4 and OpenLDAP 2.5+ in terms of linking.

Archlinux now uses OpenLDAP 2.6, hence python-ldap is not installable anymore.

As a workaround create the file /usr/lib64/libldap_r.so with content INPUT ( libldap.so ). The approach works on all systems that use a GNU ld-compatible linker.

# cat > /usr/lib64/libldap_r.so << EOF
INPUT ( libldap.so )
EOF

At this point, if any vulnerabilities come out against OpenLDAP 2.4, they won't issue a fix for the 2.4.x branch and python-ldap doesn't support a newer version. See details below. I saw earlier in this issue that supporting OpenLDAP 2.5+ is non-trivial. Do you have a list of issues you need help on? I might be able to take a shot at some over the holidays.

OpenLDAP 2.4 is EOL as of 2021-10-25 when OpenLDAP 2.6.0 came out:

• https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/thread/5RJ3FXOE2C3UGJSHOV4AIR4DXEPPWD6P/
• https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/thread/IHS5V46H6NFNFUERMC6AWMPHTWRVNLFA/

The last version of OpenLDAP 2.4.x was 2.4.59 released 2021-06-03 and per the release maintenance policy (first link above), there won't be any more updates to 2.4.x even for critical security problems: https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/thread/UREG3X43QNEQGAVSKLHKO752QVVNRQPP/

One other data point to share while I was researching: the last CVE for OpenLDAP 2.4.x was CVE-2021-27212 on 2021-02-14 and a fix was released with OpenLDAP 2.4.58 on 2021-03-16:

• https://www.cvedetails.com/cve/CVE-2021-27212/
• https://bugs.openldap.org/show_bug.cgi?id=9454
• https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/thread/GK4OGTM6VMIAJCAZSG66VXRRN2LVQDVF/

At this point, if any vulnerabilities come out against OpenLDAP 2.4, they won't issue a fix for the 2.4.x branch and python-ldap doesn't support a newer version. See details below. I saw earlier in this issue that supporting OpenLDAP 2.5+ is non-trivial. Do you have a list of issues you need help on? I might be able to take a shot at some over the holidays.

I work on OpenLDAP 2.5+ change for Fedora - https://fedoraproject.org/wiki/Changes/Openldap_25 . And python-ldap support is the thing I'll be taking care of. Basically, I have a working version of openldap-2.6.0 already on Fedora Rawhide but it'll be released only after other Fedora projects port their packages.
I'll provide all of the help for them so I hope it'll be resolved soon (before Fedora 36 release).

As a workaround create the file /usr/lib64/libldap_r.so with content INPUT ( libldap.so ). The approach works on all systems that use a GNU ld-compatible linker.

# cat > /usr/lib64/libldap_r.so << EOF
INPUT ( libldap.so )
EOF

It seems like

$ ln -s /usr/lib64/libldap.so /usr/lib64/libldap_r.so

fixes this issue as well (at least works with my Django app) and seems a little more straightforward. @tiran Can you confirm that as an equivalent workaround?

FWIW: Work on FreeBSD is underway: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258297. In the meantime one can use libmap.conf(5) to map libraries.

Hey, if i'm not wrong the latest version does still not include that fix. Maybe the issue should stay open until a new version is released?

thanks!

this will not be fixed if no one makes this report on openldap

quanah and mistotebe are both OpenLDAP core developers, we're all fully aware of this issue. There is nothing to fix on OpenLDAP's side.