openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

[Issue 10331] New: slap* tools should be a little more helpful as to which command line option was invalid
by openldap-its＠openldap.org 25 Apr '25

25 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10331 Issue ID: 10331 Summary: slap* tools should be a little more helpful as to which command line option was invalid Product: OpenLDAP Version: unspecified 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: --- Also why where appropriate. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[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 1

[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 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs