openldap-bugs October 2026

openldap-bugs@openldap.org

1 participants
6 discussions

[Issue 10581] New: Mismatch of crypt() prototype on PPC Mac OS X 10.5.8, Leopard
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10581 Issue ID: 10581 Summary: Mismatch of crypt() prototype on PPC Mac OS X 10.5.8, Leopard Product: OpenLDAP Version: 2.6.14 Hardware: Other OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: Peter_Dyballa(a)Web.DE Target Milestone: --- This happens with OpenLDAP versions 2.6.13 and 2.61.4: /opt/local/bin/gcc-mp-15 -pipe -Os -arch ppc -I../../include -I../../include -isystem/opt/local/include/LegacySupport -I/opt/local/include -I/opt/local/include/db48 -I/opt/local/include/openssl -DBIND_8_COMPAT -DMDB_FDATASYNC=fsync -DMDB_DSYNC=O_SYNC -c -o passwd.o passwd.c In file included from passwd.c:38: ../../include/ac/crypt.h:26:23: error: conflicting types for 'crypt'; have 'char *(void)' 26 | extern char *(crypt)(); | ^~~~~ In file included from /opt/local/include/LegacySupport/unistd.h:87, from ../../include/ac/unistd.h:25, from passwd.c:34: /usr/include/unistd.h:424:10: note: previous declaration of 'crypt' with type 'char *(const char *, const char *)' 424 | char *crypt(const char *, const char *); | ^~~~~ passwd.c: In function 'lutil_crypt': passwd.c:627:20: error: too many arguments to function 'crypt'; expected 0, have 2 627 | char *cr = crypt( key, salt ); | ^~~~~ ~~~ ../../include/ac/crypt.h:26:23: note: declared here 26 | extern char *(crypt)(); | ^~~~~ make[2]: *** [passwd.o] Error 1 make[2]: Leaving directory `/opt/local/var/macports/build/openldap-afe672a1/work/openldap-2.6.14/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/opt/local/var/macports/build/openldap-afe672a1/work/openldap-2.6.14/libraries' make: *** [all-common] Error 1 make: Leaving directory `/opt/local/var/macports/build/openldap-afe672a1/work/openldap-2.6.14' Command failed: cd "/opt/local/var/macports/build/openldap-afe672a1/work/openldap-2.6.14" && /usr/bin/make -w all Exit code: 2 On Leopard /usr/include/unistd.h has: char *crypt(const char *, const char *); So I ended applying this simple patch: --- include/ac/crypt.h~ 2026-08-06 18:45:16.000000000 +0200 +++ include/ac/crypt.h 2026-08-30 11:21:21.000000000 +0200 @@ -22,8 +22,6 @@ /* crypt() may be defined in a separate include file */ #ifdef HAVE_CRYPT_H # include <crypt.h> -#else - extern char *(crypt)(); #endif #endif /* _AC_CRYPT_H */ This happens when using the MacPorts package manager. The issue can be viewed (and also commented) here: https://trac.macports.org/ticket/73673. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8884 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- Fixed in git 2b8cbe0aace6d7eea7a8b93a90afdbb94b81a0a9 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=8884 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- Perhaps the code in rwm assumed the frontend would attach entryDN after the overlays transformations were completed. But clearly that's not what happens. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10590] New: sssvlv rejects multiple sort keys with protocolError in OpenLDAP 2.6.15
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10590 Issue ID: 10590 Summary: sssvlv rejects multiple sort keys with protocolError in OpenLDAP 2.6.15 Product: OpenLDAP Version: 2.6.15 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: christian(a)roessner.email Target Milestone: --- Created attachment 1204 --> https://bugs.openldap.org/attachment.cgi?id=1204&action=edit repro.go: anonymous RootDSE one-key versus two-key sorting (go-ldap v3.4.14) OpenLDAP 2.6.15 with the sssvlv overlay rejects a valid server-side sorting control containing two keys with: LDAP Result Code 2 "Protocol Error": serverSort control: decoding error A single key succeeds. Two keys fail with and without the simple paged results control. Reproduced using go-ldap/v3 v3.4.14, including an anonymous RootDSE base search. Tested pairs: cn + uid and uniqueIdentifier + uid, with caseIgnoreOrderingMatch explicitly selected for both keys. The application binds before requesting its initial sorted page, so this presents to users as a connection failure despite successful authentication. Environment: OpenLDAP 2.6.15 in a Linux x86_64 container (chrroessner/openldap LTS), on an AlmaLinux 10.2 host; client Go / macOS x86_64. The configuration loads sssvlv and enables overlay sssvlv. No sort-key limit override is configured (default five). A pristine upstream build has not yet been run for comparison. REPRODUCTION The attached repro.go sends only anonymous RootDSE searches, without reading directory accounts or writing data. Run against a disposable local server with sssvlv registered and a localhost LDAP listener on port 1389: mkdir ldap-sort-repro && cd ldap-sort-repro go mod init example.org/ldap-sort-repro go get github.com/go-ldap/ldap/v3@v3.4.14 # Copy the attached repro.go into this directory. go run . Expected: valid one-key and two-key requests are accepted. Observed on 2.6.15: the one-key case succeeds; both two-key cases return the diagnostic above. SUSPECTED CAUSE In servers/slapd/overlays/sssvlv.c, build_key(), comparison of upstream tags OPENLDAP_REL_ENG_2_6_13 and OPENLDAP_REL_ENG_2_6_15 shows the closing ber_scanf(ber, "}") replaced with: if (( tag = ber_peek_tag( ber, &len )) != LBER_DEFAULT ) { rs->sr_text = "serverSort control: decoding error"; rs->sr_err = LDAP_PROTOCOL_ERROR; return rs->sr_err; } The parser still shares the enclosing SortKeyList BER cursor across keys. After the first valid key, the next key's SEQUENCE remains in the cursor, so this check rejects a valid second key. This source change matches the observed diagnostic. The initial sequence handling also changed from ber_scanf to ber_skip_tag. The intended validation appears to require enforcing the boundary of the current SortKey SEQUENCE, while permitting the next key in SortKeyList. Simply accepting arbitrary trailing BER would not be an appropriate fix. Source: https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_15/s… Potentially related: ITS#10564, which records the sss_parseCtrl tightening (RE26 commit 6c0323aa). This report concerns rejection of valid sibling sort keys, not the malformed-input issue reported there. The release branch and current master source inspected on 2026-09-14 contain the same build_key() end-of-input check. This is source inspection, not a master runtime test. No live comparison against 2.6.13 was performed, so this report does not claim a verified first affected release. TEMPORARY CLIENT MITIGATION On the exact diagnostic above, retry only an initial search (no active paging cookie) with the primary sort key alone. Preserve that key for subsequent pages and cursor release. This drops the UID tie-breaker for equal primary values. Other errors remain visible. Suggested regression coverage: two and three keys, optional orderingRule/reverseOrder, paging continuation and cursor release, plus malformed/trailing BER rejection. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10589] New: multiple issues with ppolicy rules and rehash in ppolicy
by openldap-its＠openldap.org 01 Oct '26

01 Oct '26

https://bugs.openldap.org/show_bug.cgi?id=10589 Issue ID: 10589 Summary: multiple issues with ppolicy rules and rehash in ppolicy Product: OpenLDAP Version: 2.7.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Created attachment 1202 --> https://bugs.openldap.org/attachment.cgi?id=1202&action=edit OpenLDAP Configuration Hello, I have tested recently the new ppolicy features of OpenLDAP 2.7.1. Thanks for this great work! The new features sound really exciting. Nevertheless, I have encountered some issues during testing. As these are new features, I don't know if this is a misconfiguration problem coming from me, or if there are bugs. You can find attached the configuration and data I have used. 1. I noticed that pwdPolicySubentry as static attribute is now deprecated. How could we assign directly a specific policy to a user in the future? 2. Using olcPPolicyRuleGroupAttr attribute in a scope rule generates a coredump while OpenLDAP tries to evaluate the assigned ppolicy. (ie during user entry loading). See the configuration. 3. I tried to configure a regex rule for assigning password policies. OpenLDAP crashes when trying to compute the assigned ppolicy. (when searching a user entry matching the policy). Maybe I have not correctly defined the regex rule, but I found no concrete example of this in documentation or unit tests. 4. Trying to run OpenLDAP in debug mode with TRACE level. (-d -1), whith given configuration and data makes OpenLDAP crash at startup, with no special log. It is due to scope and regex rules, as when I remove them, OpenLDAP starts normally. 5. For pwdRehashOnBind feature, I didn't understand the "If pwdReset is set to "TRUE"" part in the man page. The current behaviour I observed is that when pwdReset is TRUE, the password is never rehashed. What is the intent here? 6. When I try to modify a password from a user having a directly assigned ppolicy (pwdPolicySubentry defined statically), the password is never rehashed. Thanks in advance for your help! -- You are receiving this mail because: You are on the CC list for the issue.

1 9

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

01 Oct '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 8

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2026