openldap-bugs

openldap-bugs@openldap.org

1 participants
21487 discussions

[Issue 10582] New: The method 'date -u -r ... %T' to print time periods when testing is incorrectly implemented
by openldap-its＠openldap.org 02 Sep '26

02 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10582 Issue ID: 10582 Summary: The method 'date -u -r ... %T' to print time periods when testing is incorrectly implemented Product: OpenLDAP Version: 2.6.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: Peter_Dyballa(a)Web.DE Target Milestone: --- 'date -u -r ... %T' works when "..." stands for a file name. Otherwise one gets: In tests/scripts/all the decision is made which date utility has to be controlled: # check for BSD vs GNU date date -j >/dev/null 2>&1 RC=$? if [ $RC -ne 0 ]; then DATEOPT="-d @" else DATEOPT="-r " fi On Macs 'date -j' produces useful output (So 30 Aug 2026 18:57:39 CEST), so it's decided to use -r on Macs – which implies that the argument following this option is a file. And so date has to complain: date: 0: No such file or directory ... date: 23: No such file or directory ... It might work to change the time() function become for example: timer() { if [ -n "$STARTTIME" ]; then now=`date +%s` delta=`expr $now - $STARTTIME` touch $delta date -u $DATEOPT $delta +%T fi } For Macs it might work to patch tests/scripts/all to start with gdate -j >/dev/null 2>&1 Then timer() would use -d @ which gdate and the macOS systems' date do understand. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10579] New: tlso_sb_{read,write} don't handle the opposite condition
by openldap-its＠openldap.org 01 Sep '26

01 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10579 Issue ID: 10579 Summary: tlso_sb_{read,write} don't handle the opposite condition Product: OpenLDAP Version: 2.7.0 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: --- With non-blocking BIO (lloadd), a SSL_write can error out with SSL_ERROR_WANT_READ and vice versa, e.g. at renegotiation or more points if TLS 1.3 is in place. Without knowing that, lloadd (or other applications if we ever say non-blocking OpenSSL use is supported) cannot make the right decisions, e.g. close a healthy connection. Of course lloadd also needs to expect this situation and arm the correct callback otherwise things get even worse. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10578] New: libldap never clears OpenSSL error queue so SSL_get_error() can misreport on OpenSSL <4.0
by openldap-its＠openldap.org 01 Sep '26

01 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10578 Issue ID: 10578 Summary: libldap never clears OpenSSL error queue so SSL_get_error() can misreport on OpenSSL <4.0 Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- SSL_get_error() needs the calling thread's error queue to be empty before the SSL_* calls that could have produced one but we never make sure that's the case. SSL_get_error() doesn't actually clear the error from the queue, so if a SSL_* call returns an error on OpenSSL <4.0, it stays around as poison. This can manifest e.g. as an otherwise healthy connection being suddenly terminated with a reason that doesn't track. We should just call ERR_clear_error() before every SSL_* call that can set it to get something meaningful back. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10577] New: Memory leak in client-side libldap response handling when a malformed BER message causes an error.
by openldap-its＠openldap.org 01 Sep '26

01 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10577 Issue ID: 10577 Summary: Memory leak in client-side libldap response handling when a malformed BER message causes an error. Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: thetrenshow157(a)gmail.com Target Milestone: --- Created attachment 1195 --> https://bugs.openldap.org/attachment.cgi?id=1195&action=edit Reproduction script During client-side libldap fuzzing, a memory leak was found when processing a malformed BER response. If a response contains a valid message ID matching an outstanding request, `ldap_find_request_by_msgid()` increments the `LDAPRequest` reference count. If the following TLV declares a length larger than the remaining BER data, `ber_peek_tag()` returns `LBER_ERROR` and `try_read1msg()` returns `-1` without releasing the acquired request reference. As a result, the `LDAPRequest` and its associated allocations are leaked. The attached reproducer triggers the issue with a malformed BindResponse, but the issue is not specific to the request type. The Valgrind log was collected with OpenLDAP 2.6.8, but the memory leak is still reproducible on the latest development branch. Although such a malformed response is not expected from a compliant server, it would still be better to handle this error path without leaking memory. I have attached the reproducer script and the Valgrind log to this message. Valgrind log: ==307307== Memcheck, a memory error detector ==307307== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==307307== Using Valgrind-3.26.0 and LibVEX; rerun with -h for copyright info ==307307== Command: ldapsearch -x -H ldap://127.0.0.1:37095/ -D cn=Directory\ Manager -w password -b dc=example,dc=com -s base (objectClass=*) -o nettimeout=2 -l 2 ==307307== ldap_result: Can't contact LDAP server (-1) ==307307== ==307307== HEAP SUMMARY: ==307307== in use at exit: 4,290 bytes in 4 blocks ==307307== total heap usage: 165 allocs, 161 frees, 106,847 bytes allocated ==307307== ==307307== 4,276 (136 direct, 4,140 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4 ==307307== at 0x48664A4: calloc (vg_replace_malloc.c:1678) ==307307== by 0x48E7A4C: ber_memcalloc_x (memory.c:283) ==307307== by 0x48AA75A: ldap_send_server_request (request.c:349) ==307307== by 0x48AAD8F: ldap_send_initial_request (request.c:169) ==307307== by 0x489B296: ldap_sasl_bind (sasl.c:164) ==307307== by 0x400F226: tool_bind (common.c:1593) ==307307== by 0x400593A: main (ldapsearch.c:1109) ==307307== ==307307== LEAK SUMMARY: ==307307== definitely lost: 136 bytes in 1 blocks ==307307== indirectly lost: 4,140 bytes in 2 blocks ==307307== possibly lost: 0 bytes in 0 blocks ==307307== still reachable: 14 bytes in 1 blocks ==307307== suppressed: 0 bytes in 0 blocks ==307307== Reachable blocks (those to which a pointer was found) are not shown. ==307307== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==307307== ==307307== For lists of detected and suppressed errors, rerun with: -s ==307307== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10583] New: lloadd logging enhancements
by openldap-its＠openldap.org 01 Sep '26

01 Sep '26

https://bugs.openldap.org/show_bug.cgi?id=10583 Issue ID: 10583 Summary: lloadd logging enhancements Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- The logs do not contain the bind result or the identity of the caller which complicates troubleshooting issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

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

01 Sep '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 1

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

29 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 6

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

25 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 12

[Issue 10576] New: modify dn is not logged when STATS2 is on
by openldap-its＠openldap.org 20 Aug '26

20 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10576 Issue ID: 10576 Summary: modify dn is not logged when STATS2 is on Product: OpenLDAP Version: 2.7.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- ITS#9042 hid the line in the else branch, it should be outside the if with a STATS|STATS2 filter. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

20 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 4

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