openldap-bugs

openldap-bugs@openldap.org

1 participants
21477 discussions

[Issue 10572] New: please add mdb_env_get_maxkeysize() to upgrading.doc for 1.0.x
by openldap-its＠openldap.org 18 Aug '26

18 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10572 Issue ID: 10572 Summary: please add mdb_env_get_maxkeysize() to upgrading.doc for 1.0.x Product: LMDB Version: 1.0.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: matthias.andree(a)gmx.de CC: steffen(a)sdaoden.eu Target Milestone: --- https://git.openldap.org/openldap/openldap/-/commit/136667a1492ea624b8d8bee… updated the mdb_env_get_maxkeysize() documentation for the LMDB_1.0.1 release such that it now correctly mentions it must be called after mdb_env_open() rather than mdb_env_create() (as was sufficient in 0.9.x), in response to a defect report from Steffen here https://bugs.openldap.org/show_bug.cgi?id=10534. Please add a relevant line that mdb_env_get_maxkeysize() can now (as of 1.0.0) only be called after mdb_env_open() to upgrading.doc so that LMDB users are aware they may need to move the mdb_env_get_maxkeysize() call in their code. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10564] A single anonymous LDAP search with a crafted server-side-sort control heap-overflows the OpenLDAP slapd worker
by openldap-its＠openldap.org 18 Aug '26

18 Aug '26

1 0

[Issue 10574] New: request_process can desync
by openldap-its＠openldap.org 18 Aug '26

18 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10574 Issue ID: 10574 Summary: request_process can desync Product: OpenLDAP Version: 2.6.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Failing to allocate an upstream on a "write" tagged op, c_restricted_inflight is not incremented but o_restricted still claims op's cone of focus is WRITE, freeing that op then decrements counter spuriously. We need to reset o_restricted if we didn't commit the restrictions on the rejection paths. Related to ITS#10510, which only closed one half of the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10563] New: ldap_count_message() returns '1' even with empty LDAPMessage as input.
by openldap-its＠openldap.org 18 Aug '26

18 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10563 Issue ID: 10563 Summary: ldap_count_message() returns '1' even with empty LDAPMessage as input. 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: feh(a)fehcom.de Target Milestone: --- Source: libldap/messages.c The function int ldap_count_messages( LDAP *ld, LDAPMessage *chain ) given *chain is NULL will return a '1' as result. Line numbers included: 49 int 50 ldap_count_messages( LDAP *ld, LDAPMessage *chain ) 51 { 52 int i; 53 54 assert( ld != NULL ); 55 assert( LDAP_VALID( ld ) ); 56 57 for ( i = 0; chain != NULL; chain = chain->lm_chain ) { 58 i++; 59 } 60 61 return( i ); 62 } It would be sufficient to test the LDAP message *chain in the following way before the for loop is executed: line 56: if (!chain && !*chain) return ( 0 ); --eh. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10568] New: Client tools segfault when run without arguments
by openldap-its＠openldap.org 18 Aug '26

18 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10568 Issue ID: 10568 Summary: Client tools segfault when run without arguments Product: OpenLDAP Version: 2.7.0 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: nzb_tuxxx(a)proton.me Target Milestone: --- When the default connection fails, several client tools call `strlen(ldapuri)` while `ldapuri` is `NULL`. Steps to reproduce: 1. Run `ldapadd`, `ldapdelete`, `ldapmodify`, `ldapmodrdn`, `ldappasswd`, `ldapsearch`, `ldapvc`, or `ldapwhoami` without arguments. 2. Observe `Segmentation fault (core dumped)` and exit status 139. References: - Regression: https://git.openldap.org/openldap/openldap/-/commit/37d677fb8d16b05a387c9f9… - Downstream report: https://gitlab.archlinux.org/archlinux/packaging/packages/openldap/-/work_i… -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10573] New: OpenLDAP 2.7.0 fails to build with MSVC when preprocessing symbol version maps
by openldap-its＠openldap.org 18 Aug '26

18 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10573 Issue ID: 10573 Summary: OpenLDAP 2.7.0 fails to build with MSVC when preprocessing symbol version maps Product: OpenLDAP Version: 2.7.0 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: openldap-msvc-673e3a64ee4f43(a)emalupe.com Target Milestone: --- OpenLDAP 2.7.0 fails to build with MSVC while generating the liblber symbol version map. The regression appears to have been introduced by commit 8651f98a08c37bea6ee9be78acececd52bac66a0 (ITS#9739). The new rules in libraries/liblber/Makefile.in and libraries/libldap/Makefile.in invoke: $(CPP) -x c -o $@ $(LT_CPPFLAGS) $(srcdir)/$(SYMBOL_VERSION_SCRIPT).in The -x c option is specific to GCC/Clang. When Autoconf's configured C preprocessor is MSVC (cl -E), cl ignores -x and treats the following c as an input filename: cl : Command line warning D9002 : ignoring unknown option '-x' c1: fatal error C1083: Cannot open source file: 'c': No such file or directory make[2]: *** [Makefile:301: lber.map] Error 2 This was reproduced with OpenLDAP 2.7.0 and Visual Studio 2026/MSVC 14.51 on Windows. OpenLDAP 2.6.13 builds successfully with the same compiler setup because it does not preprocess these map files. The same non-portable invocation is present in both the liblber and libldap map-generation rules and remains in the current OPENLDAP_REL_ENG_2_7 and master branches. Could the hard-coded compiler language option be removed or replaced with a configure-detected, compiler-portable way to preprocess the .map.in files? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10571] New: Asyncmeta's conn-ttl optional reset-interval argument silently defaults to the TTL
by openldap-its＠openldap.org 18 Aug '26

18 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10571 Issue ID: 10571 Summary: Asyncmeta's conn-ttl optional reset-interval argument silently defaults to the TTL Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- mc->mc_conn_reset_interval is set to TTL if the 1 argument form is configured (no value for <interval> provided) but as per manpage it should default to `1` instead. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10569] New: Makefile, lmdb.pc file show version 1.0.0
by openldap-its＠openldap.org 18 Aug '26

18 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10569 Issue ID: 10569 Summary: Makefile, lmdb.pc file show version 1.0.0 Product: LMDB Version: 1.0.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: trivial Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The LMDB_VERSION in the Makefile wasn't updated. Makefile will be patched to obtain the version from the built binaries. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10510] New: write_coherence can assert() on unbind
by openldap-its＠openldap.org 17 Aug '26

17 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10510 Issue ID: 10510 Summary: write_coherence can assert() on unbind Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If lloadd links a client with a backend and that client issues a write and unbind in quick succession, the self-checks in client_reset are overly strict, triggering an assert. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10570] New: Humble request for comment about cached pagination
by openldap-its＠openldap.org 14 Aug '26

14 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10570 Issue ID: 10570 Summary: Humble request for comment about cached pagination Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: f.castagnan(a)gmail.com Target Milestone: --- Hello folks, I hope you are well and thank you for providing a forum for users to raise inquiries, I think the structured format is quite good. (it's my first time doing raising an issue on your platform) Context: I have this query shape that is quite expensive, coming in from python ldap3 lib used in many of my clients. I decided to put openldap using the pcache overlay between my clients are my AD servers to cache the results. ```python # The python code using ldap3 python lib # Below expands to (&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=cn=<group>,ou=REDACTED,ou=REDACTED,ou=REDACTED,ou=REDACTED,dc=REDACTED,dc=com)) for entry in conn.extend.standard.paged_search( search_base, search_filter, scope, attributes=list(attributes), paged_size=page_size, generator=True, ): ``` I am using these attribute sets and templates (cropped for brevity) ``` ... database ldap suffix "dc=REDACTED" uri ldap://REDACTED.com/ overlay pcache pcache mdb 100000 6 1000 100 pcacheAttrset 0 uidNumber gidNumber sAMAccountName loginShell sn pcacheAttrset 1 member uidNumber gidNumber loginShell sAMAccountName memberOf cn name pcacheAttrset 2 whenCreated mail sAMAccountName cn objectclass whenChanged userprincipalname uidNumber objectGUID sn memberOf userPrincipalName userAccountControl pwdLastSet loginShell pcacheAttrset 3 cn name sAMAccountName memberOf uidNumber gidNumber distinguishedName unixHomeDirectory REDACTED pcacheAttrset 4 gidNumber sAMAccountName pcacheAttrset 5 name member gidNumber sAMAccountName cn pcacheTemplate (&(objectClass=)(gidNumber=)) 0 10800 pcacheTemplate (&(objectClass=)(gidNumber=)) 4 10800 pcacheTemplate (&(objectClass=)(cn=)) 1 10800 pcacheTemplate (&(objectClass=group)(cn=)) 1 10800 pcacheTemplate (sAMAccountName=) 0 3600 ... ``` Problem observed I can't seem to get the paged queries to be cached and it only returns my AD server max limit of 1000 items even when there are more results leading to inacurrate results in my clients. ``` # LOGS 6a7cd2f0.2447015f 0x7f65effff640 conn=53266 op=3 SRCH base="ou=REDACTED,dc=com" scope=2 deref=3 filter="(&(objectClass=user)(!(objectClass=computer)))" 6a7cd2f0.2447c7b1 0x7f65effff640 conn=53266 op=3 SRCH attr=unixHomeDirectory sAMAccountName REDACTED uidNumber gidNumber name cn distinguishedName memberOf 6a7cd2f0.24480fd2 0x7f65effff640 conn=53266 op=3: non-critical pagedResults control disabled with proxy cache; stripped. 6a7cd2f0.244819ea 0x7f65effff640 conn=53266 op=3: non-critical control "1.2.840.113556.1.4.1339" not supported; stripped. 6a7cd2f0.24484d6b 0x7f65effff640 query template of incoming query = (&(objectClass=)(!(objectClass=))) 6a7cd2f0.24485ba0 0x7f65effff640 QUERY NOT ANSWERABLE 6a7cd2f0.24486181 0x7f65effff640 QUERY NOT CACHEABLE ``` I tried a number of permutation to fix this, but upon inspecting the code it seems that pagination is explicitly not supported. From this line: https://github.com/openldap/openldap/blob/fe9c74b257398deab91ef2ec69011df3c… Questions: 1. Is there an accepted design for adding pagedResults support to pcache (cookie handling, stable ordering, cursor state)? 2. Is there a recommended way to cache paged searches or to internally page cached results while forwarding a single non‑paged search to the backend? 3. Are there existing patches or modules that solve this (or similar) in OpenLDAP? Many thanks! Francis -- You are receiving this mail because: You are on the CC list for the issue.

1 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs