openldap-bugs April 2025

openldap-bugs@openldap.org

1 participants
18 discussions

[Issue 10324] New: Grammar error
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10324 Issue ID: 10324 Summary: Grammar error Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ron(a)return.sh Target Milestone: --- In the documentation, y'all have: Acknowledgments The OpenLDAP Project is comprised of a team of volunteers. This document would not be possible without their contribution of time and energy. Either "comprises" or "composed of" should be used. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=6938 --- Comment #5 from Dhiraj Giria <dhiraj.giria(a)mitel.com> --- Thank you Matt, I have tried using mingw32 and mingw64 under MSYS2 environment. Using mingw32 and mingw64 fails during the configure step. Error while running mingw32: configure: error: IPv6 support requires getaddrinfo() and inet_ntop() Error with mingw64: Unable to load winsock.h and winsock2.h files as they collide with linux based socket libraries under sys folders. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10330] New: TIMEOUT and NETWORK_TIMEOUT not respected when receiving bad data during TLS negotiation
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10330 Issue ID: 10330 Summary: TIMEOUT and NETWORK_TIMEOUT not respected when receiving bad data during TLS negotiation Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.kourlas(a)solace.com Target Milestone: --- Created attachment 1063 --> https://bugs.openldap.org/attachment.cgi?id=1063&action=edit Test program This seems related to bug 8047. Steps to reproduce: 1. Setup a netcat server on a host: "nc -l -k -p 636". 2. On a different host, attempt to connect to the host running "nc" as if it were an LDAP server via ldaps: "ldapsearch -o NETWORK_TIMEOUT=5 -o TIMEOUT=5 -H ldaps://<ip>:636". 3. During the 5 second timeout period, switch back to the netcat server and transmit a newline by pressing enter. 4. ldapsearch will hang forever until the TCP connection is closed (e.g. by killing the netcat server). My expectation would be that ldapsearch would exit after 5 seconds, per the NETWORK_TIMEOUT and TIMEOUT options. I'm using the following version of ldapsearch on Fedora 41 (x86-64): > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.9 (Mar 27 2025 00:00:00) $ > openldap > (LDAP library: OpenLDAP 20609) This problem is also observable when directly using the OpenLDAP C API. This is more of an issue, since any application using the API could become unresponsive if these timeout values aren't respected. I've attached a short test program which can be used instead of ldapsearch. If I abort the test program while it is stuck in this state, the traceback looks like this: > #0 0x00007f50b7a25811 in __GI___libc_read (fd=3, buf=0x2aaf9ac5, nbytes=3) at ../sysdeps/unix/sysv/linux/read.c:26 > #1 0x00007f50b792f8b9 in sb_debug_read (sbiod=0x2aadf390, buf=0x2aaf9ac5, len=3) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/liblber/sockbuf.c:829 > #2 0x00007f50b7b61156 in tlso_bio_read (b=0x2aadf9c0, buf=0x2aaf9ac5 "", len=3) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls_o.c:1279 > #3 0x00007f50b7221ea3 in bread_conv (bio=<optimized out>, data=<optimized out>, datal=<optimized out>, readbytes=0x7ffd1cf2e3f0) > at crypto/bio/bio_meth.c:121 > #4 0x00007f50b7226047 in bio_read_intern (b=b@entry=0x2aadf9c0, data=0x2aaf9ac5, data@entry=0x555f3588, dlen=3, dlen@entry=18446744072487067717, > readbytes=readbytes@entry=0x7ffd1cf2e3f0) at crypto/bio/bio_lib.c:285 > #5 0x00007f50b72261db in BIO_read (b=0x2aadf9c0, data=0x555f3588, dlen=-1222483899) at crypto/bio/bio_lib.c:311 > #6 BIO_read (b=b@entry=0x2aadf9c0, data=data@entry=0x2aaf9ac5, dlen=dlen@entry=3) at crypto/bio/bio_lib.c:303 > #7 0x00007f50b783ce03 in tls_default_read_n (rl=0x2aaec1c0, n=5, max=<optimized out>, extend=<optimized out>, clearold=<optimized out>, > readbytes=0x7ffd1cf2e4b8) at ssl/record/methods/tls_common.c:406 > #8 0x00007f50b784151b in tls_get_more_records (rl=0x2aaec1c0) at ssl/record/methods/tls_common.c:583 > #9 0x00007f50b783b8ea in tls_read_record (rl=0x2aaec1c0, rechandle=0x2aaeb600, rversion=0x2aaeb608, type=0x2aaeb60c "", data=0x2aaeb610, > datalen=0x2aaeb620, epoch=0x0, seq_num=0x0) at ssl/record/methods/tls_common.c:1130 > #10 0x00007f50b783969a in ssl3_read_bytes (ssl=<optimized out>, type=22 '\026', recvd_type=0x7ffd1cf2e684 "", buf=0x2aaee480 "\001", len=4, > peek=0, readbytes=0x7ffd1cf2e688) at ssl/record/rec_layer_s3.c:689 > #11 0x00007f50b784f5a7 in tls_get_message_header (s=0x2aaea980, mt=<synthetic pointer>) at ssl/statem/statem_lib.c:1554 > --Type <RET> for more, q to quit, c to continue without paging-- > #12 read_state_machine (s=0x2aaea980) at ssl/statem/statem.c:625 > #13 state_machine (s=<optimized out>, server=0) at ssl/statem/statem.c:479 > #14 0x00007f50b7b615c3 in tlso_session_connect (ld=<optimized out>, sess=0x2aaea980, name_in=<optimized out>) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls_o.c:693 > #15 0x00007f50b7b65bf2 in ldap_int_tls_connect (ld=ld@entry=0x2a9b2430, conn=conn@entry=0x2a9b25d0, host=host@entry=0x2a9b2550 "192.168.133.56") > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls2.c:425 > #16 0x00007f50b7b6636f in ldap_int_tls_start (ld=0x2a9b2430, conn=0x2a9b25d0, srv=<optimized out>) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls2.c:1245 > #17 0x00007f50b7b3d4c2 in ldap_int_open_connection (ld=0x2a9b2430, conn=0x2a9b25d0, srv=0x2a9b24d0, async=0) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/open.c:515 > #18 0x00007f50b7b5212d in ldap_new_connection (ld=0x2a9b2430, srvlist=0x2a9b2878, use_ldsb=1, connect=<optimized out>, bind=0x0, m_req=0, m_res=0) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/request.c:491 > #19 0x00007f50b7b3c7b4 in ldap_open_defconn (ld=0x2a9b2430) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/open.c:42 > #20 0x00007f50b7b52ed8 in ldap_send_initial_request (ld=0x2a9b2430, msgtype=96, dn=0x4023a9 "cn=admin,dc=solace,dc=com", ber=0x2a9b2570, msgid=1) > at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/request.c:131 > #21 0x00007f50b7b429b9 in ldap_sasl_bind (ld=0x2a9b2430, dn=0x4023a9 "cn=admin,dc=solace,dc=com", mechanism=0x0, cred=0x7ffd1cf2eb90, sctrls=0x0, > cctrls=0x0, msgidp=0x7ffd1cf2eb8c) at /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/sasl.c:164 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=6938 --- Comment #4 from Matthew Hardin <mhardin(a)symas.com> --- Hello, Yes, I have confirmed that there are issues building OpenLDAP under MSYS2 with --enable-ipv6. What environment are you building under? Thanks, -Matt > On Apr 24, 2025, at 3:03 AM, openldap-its(a)openldap.org wrote: > > https://bugs.openldap.org/show_bug.cgi?id=6938 > > --- Comment #3 from Dhiraj Giria <dhiraj.giria(a)mitel.com> --- > Hi Matt > I have tried building OpenLDAP 2.6.9 version with flag enable-ipv6 flag for > Windows environment, but failed to do so successfully. Is it a valid ticket? > can you please confirm if we support openldap+ipv6 on Windows? > > Thanks > Dhiraj > > -- > You are receiving this mail because: > You are the assignee for the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=6938 --- Comment #3 from Dhiraj Giria <dhiraj.giria(a)mitel.com> --- Hi Matt I have tried building OpenLDAP 2.6.9 version with flag enable-ipv6 flag for Windows environment, but failed to do so successfully. Is it a valid ticket? can you please confirm if we support openldap+ipv6 on Windows? Thanks Dhiraj -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10329] New: Additional issues with pcache, and a test
by openldap-its＠openldap.org 23 Apr '25

23 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10329 Issue ID: 10329 Summary: Additional issues with pcache, and a test Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: aweits(a)rit.edu Target Milestone: --- Created attachment 1062 --> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit test & patches Hello again! Further testing revealed some more issues in pcache [re: ITS#10270]. I've attached an update to test020-proxycache as well. These are based off the current git HEAD. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10328] New: Possible multiple free() calls in rewrite_subst_compile()
by openldap-its＠openldap.org 22 Apr '25

22 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10328 Issue ID: 10328 Summary: Possible multiple free() calls in rewrite_subst_compile() Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: gyf161023(a)gmail.com Target Milestone: --- In rewrite_subst_compile() of libraries/librewrite/subst.c line 216 and 222, `subs` and `submatch` array are freed repeatedly on the index `nsub` instead of l, is this what was intended or the `nsub` has some guarantee to be 1 so that we are not freeing anything for second time? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10326] New: SNI passing requirements differ across TLS implementations
by openldap-its＠openldap.org 22 Apr '25

22 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10326 Issue ID: 10326 Summary: SNI passing requirements differ across TLS implementations Product: OpenLDAP Version: unspecified 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: --- mbedtls 3.6.3 has changed behaviour to correct a long standing issue where not setting a hostname meant hostname checking was disabled completely (CVE-2025-27809). It seems that how we do SNI vs. basic certificate checking differs between TLS implementations and our logic in ldap_int_tls_connect and ti_session_connect. This is also the reason test067-tls started failing on mbedtls builds. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10323] New: Starttls critical not working on lloadd
by openldap-its＠openldap.org 17 Apr '25

17 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10323 Issue ID: 10323 Summary: Starttls critical not working on lloadd Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: grichier(a)scaleway.com Target Milestone: --- Hello, Looks like starttls critical not working on lloadd. I have a backend with starttls configure but with bad CN. When I direct query the backend using ldapsearch with option -ZZ, I have the following error: ldap_start_tls: Connect error (-11) additional info: (unknown error code) But when I query the lloadd, which use same backend with olcBkLloadStartTLS to critical. It's work... On a tcpdump I can see the communication between backend and lloadd is not using starttls. (cleartext). But it shouldn't (critical option) cn: {1}ldap://ldap01.example.com olcBkLloadBackendUri: ldap://ldap01.example.com olcBkLloadNumconns: 10 olcBkLloadBindconns: 5 olcBkLloadRetry: 5000 olcBkLloadMaxPendingOps: 50 olcBkLloadMaxPendingConns: 10 olcBkLloadWeight: 1 olcBkLloadStartTLS: critical -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10254] New: Allow upgrading password hash on bind
by openldap-its＠openldap.org 15 Apr '25

15 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10254 Issue ID: 10254 Summary: Allow upgrading password hash on bind Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: me(a)floriswesterman.nl Target Milestone: --- Many OpenLDAP installations are likely to contain relatively old password hashes such as SSHA and CRYPT, as modern alternatives such as Argon are only recent additions. Due to the nature of password hashes, it is of course not possible to "unhash" the old values and rehash them with a more modern algorithm. The presence of these old password hashes poses a liability in case of information leaks or hacks. Currently, the only way to upgrade a password hash is to wait for the user to change their password. This can be sped up by expiring passwords and forcing users to change them. However, this can be slow and frequent password rotation is no longer considered a best practice. It would be a very helpful addition to add support for upgrading a password hash on bind. This is implemented in the 389 directory server: https://www.port389.org/docs/389ds/design/pwupgrade-on-bind.html Essentially, when a user binds, the password is checked like normal. In case of a successful bind, the proposed feature would check the hash algorithm used for the password; and in case it is not equal to the current `olcPasswordHash` value, the user-provided password is rehashed using the new algorithm and stored. This way, the old hashes are phased out more quickly, without being a disturbance to users. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2025