openldap-bugs May 2026

openldap-bugs@openldap.org

1 participants
84 discussions

[Issue 10503] saslauthz LDAP_X_SCOPE_GROUP fails to escape proxyAuthz asserted DN in internal group filter, enabling wildcard substring-filter group-membership bypass
by openldap-its＠openldap.org 14 May '26

14 May '26

https://bugs.openldap.org/show_bug.cgi?id=10503 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8461] Unable to import LDIF from back-hdb DB to back-mdb db
by openldap-its＠openldap.org 13 May '26

13 May '26

https://bugs.openldap.org/show_bug.cgi?id=8461 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Fixed by switch to lmdb 1.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10274] New: Replication issue on MMR configuration
by openldap-its＠openldap.org 13 May '26

13 May '26

https://bugs.openldap.org/show_bug.cgi?id=10274 Issue ID: 10274 Summary: Replication issue on MMR configuration Product: OpenLDAP Version: 2.5.14 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: falgon.comp(a)gmail.com Target Milestone: --- Created attachment 1036 --> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit In this attachment you will find 2 openldap configurations for 2 instances + slamd conf exemple + 5 screenshots to show the issue and one text file to explain what you see Hello we are openning this issue further to the initial post in technical : https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Issue : We are working on a project and we've come across an issue with the replication after performance testing : *Configuration :* RHEL 8.6 OpenLDAP 2.5.14 *MMR-delta *configuration on multiple servers attached 300,000 users configured and used for tests *olcLastBind: TRUE* Use of SLAMD (performance shooting) *Problem description:* We are currently running performance and resilience tests on our infrastructure using the SLAMD tool configured to perform BINDs and MODs on a defined range of accounts. We use a load balancer (VIP) to poll all of our servers equally. (but it is possible to do performance tests directly on each of the directories) With our current infrastructure we're able to perform approximately 300 MOD/BIND/s. Beyond that, we start to generate delays and can randomly come across one issue. However, when we run performance tests that exceed our write capacity, our replication between servers can randomly create an incident with directories being unable to catch up with their replication delay. The directories update their contextCSNs, but extremely slowly (like freezing). From then on, it's impossible for the directories to catch again. (even with no incoming traffic) A restart of the instance is required to perform a full refresh and solve the incident. We have enabled synchronization logs and have no error or refresh logs to indicate a problem ( we can provide you with logs if necessary). We suspect a write collision or a replication conflict but this is never write in our sync logs. We've run a lot of tests. For example, when we run a performance test on a single live server, we don't reproduce the problem. Anothers examples: if we define different accounts ranges for each server with SALMD, we don't reproduce the problem either. If we use only one account for the range, we don't reproduce the problem either. ______________________________________________________________________ I have add some screenshots on attachement to show you the issue and all the explanations. ______________________________________________________________________ *Symptoms :* One or more directories can no longer be replicated normally after performance testing ends. No apparent error logs. Need a restart of instances to solve the problem. *How to reproduce the problem:* Have at least two servers in MMR mode Set LastBind to TRUE Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple SLAMD test on same time for each server with the same account range. Exceed the maximum write capacity of the servers. *SLAMD configuration :* authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \ --useSSL --trustStorePath ${CACERTJKS} \ --trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \ --bindPassword ${BINDPW} --baseDN "${BASEDN}" \ --filter "(uid=[${RANGE}])" --credentials ${USERPW} \ --warmUpIntervals ${WARMUP} \ --numThreads ${NTHREADS} ${ARGS} -- You are receiving this mail because: You are on the CC list for the issue.

1 22

[Bug 9225] New: back-mdb: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 13 May '26

13 May '26

https://bugs.openldap.org/show_bug.cgi?id=9225 Bug ID: 9225 Summary: back-mdb: Add support for PREPARE/2-phase commit Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Add support for PREPARE/2-phase commit in back-mdb -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 13 May '26

13 May '26

https://bugs.openldap.org/show_bug.cgi?id=9009 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8461] Unable to import LDIF from back-hdb DB to back-mdb db
by openldap-its＠openldap.org 13 May '26

13 May '26

https://bugs.openldap.org/show_bug.cgi?id=8461 Issue 8461 depends on issue 9009, which changed state. Issue 9009 Summary: 2.7: Switch to LMDB v1.0 https://bugs.openldap.org/show_bug.cgi?id=9009 What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10500] New: back-ldif/ldif.c crc32() should be static — collides with zlib's crc32 at link time
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=10500 Issue ID: 10500 Summary: back-ldif/ldif.c crc32() should be static — collides with zlib's crc32 at link time Product: OpenLDAP Version: 2.6.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ionutn(a)gmail.com Target Milestone: --- In servers/slapd/back-ldif/ldif.c, the helper crc32() (defined at line 393 in 2.6.13) is declared with external linkage: unsigned int crc32(const void *vbuf, int len) { ... } It is only used inside that file (lines 470 and 511). It has the same name as zlib's public crc32() but a completely different signature and semantics — it's an internal helper for hashing LDIF entry filenames, unrelated to zlib's CRC-32-IEEE-802.3. This is a latent symbol collision that has been present for many years. Until recently, ld silently resolved zlib's crc32 references (from inflate.c.o / deflate.c.o, transitively pulled in by libcrypto) against back-ldif's crc32 — because back-ldif is linked first — and libz.a's crc32.c.o was never pulled in. NEWLY EXPOSED BY zlib 1.3.2: zlib 1.3.2's deflate.c added an internal call to crc32_z, a symbol defined only in libz.a(crc32.c.o). When slapd is linked against libssl/libcrypto + libz.a, ld now has to pull in crc32.c.o to satisfy crc32_z, which brings the public crc32 along — colliding with back-ldif's: libz.a(crc32.c.o): In function `crc32': zlib-1.3.2/crc32.c:950: multiple definition of `crc32' libbackends.a(ldifldif.o):.../back-ldif/ldif.c:399: first defined here collect2: error: ld returned 1 exit status Reproduction: any build that links slapd (or anything pulling in libbackends.a) together with libssl + libcrypto + zlib 1.3.2's libz.a. Hit on Linux/aarch64 and Linux/x86_64 with GCC 8.5 + ld from binutils. Suggested fix (one keyword) --------------------------- Mark the function static: -unsigned int +static unsigned int crc32(const void *vbuf, int len) Tested locally on 2.6.13: slapd builds cleanly against zlib 1.3.2 with this change. No behaviour change since the function is only ever called from within ldif.c. Versions -------- - Confirmed: 2.6.13 (latest) and 2.6.10. The code path appears identical going back many releases. - ld behaviour change is triggered specifically by zlib 1.3.2 (released Feb 2026). -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10495] New: Environment variable for Systemd is ignored by configure
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=10495 Issue ID: 10495 Summary: Environment variable for Systemd is ignored by configure Product: OpenLDAP Version: 2.6.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: openldap.aftermost863(a)passinbox.com Target Milestone: --- Hello, When using the configure script to generate the Makefile, the documentation in the --help option states that the environment variable 'systemdsystemunitdir' can be used to override the default system path for Systemd units. However, this does not work: if I export the variable with a valid existing path (e.g. 'export systemdsystemunitdir=/tmp/test') and then run ./configure, the variable is found but is ignored in the output variables and is therefore not used in the Makefile. config.log: ... ## ---------------- ## ## Cache variables. ## ## ---------------- ## ... ac_cv_env_systemdsystemunitdir_set=set ac_cv_env_systemdsystemunitdir_value=/tmp/test ... ## ----------------- ## ## Output variables. ## ## ----------------- ## ... systemdsystemunitdir='/usr/lib/systemd/system' ... The configure script seems to override that variable on line 23942: systemdsystemunitdir= I don’t quite understand why this line is there, and it seems suspicious to me. However, if I remove it and run ./configure again in the exact same shell, config.log now shows the correct path in the output variables, and the Makefile uses it correctly afterward: ... ## ---------------- ## ## Cache variables. ## ## ---------------- ## ... ac_cv_env_systemdsystemunitdir_set=set ac_cv_env_systemdsystemunitdir_value=/tmp/test ... pkg_cv_systemdsystemunitdir=/tmp/test ## ----------------- ## ## Output variables. ## ## ----------------- ## ... systemdsystemunitdir='/tmp/test' I had this issue on both Debian 13 (using bash) and Arch Linux (using zsh). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10498] New: libldap OpenSSL 4 compatibility
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=10498 Issue ID: 10498 Summary: libldap OpenSSL 4 compatibility Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: rainer.jung(a)kippdata.de Target Milestone: --- Created attachment 1145 --> https://bugs.openldap.org/attachment.cgi?id=1145&action=edit Patch for libldap OpenSSL 4 compatibility libldap uses direct access to struct members made opaque in OpenSSL 4. Alternative getter methods needed to access the struct members seem to be available since OpenSSL 1.1.0, so very long ago. I suggest the attached (trivial) patch to replace direct access with getter methods. The patch is based on OpenLDAP 2.6.13. From visual code inspection it seems the problem also exists in the master branch. I did not try to compile the rest of OpenLDAP with OpenSSL 4, just libldap. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10496] New: Remove references to Mozilla NSS in lload.conf(5) man page
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=10496 Issue ID: 10496 Summary: Remove references to Mozilla NSS in lload.conf(5) man page Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- We removed Mozilla NSS support in OpenLDAP 2.5, remove references to it from OpenLDAP 2.6 man pages. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2026