openldap-bugs August 2025

openldap-bugs@openldap.org

1 participants
161 discussions

[Issue 10373] New: pcache SEGV with pcacheTemplate ttr
by openldap-its＠openldap.org 23 Sep '25

23 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10373 Issue ID: 10373 Summary: pcache SEGV with pcacheTemplate ttr Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: bertrand(a)jacquin.bzh Target Milestone: --- Hi, I am currently setting up OpenLDAP with pcache to circumvent aggressive LDAP queries from an application and thus reduce load to the SQL database used in the backend through back-sql.so. The setup is incomplete and likely not currently implemented properly, please don't pay too much attention in configuration details from below, however I'm noticing SEGV when pcacheTemplate are configured with ttr: refresh_purge() attempts to dereference NULL pointer *a, leading to the SEGV: ``` $ gdb --args /usr/lib64/openldap/slapd -u ldap -h "ldapi:/// ldap:/// ldaps:///" -f /etc/openldap/slapd.conf -d stats -d pcache 688224ea.1e5f48d7 0x7fffedffb6c0 conn=1020 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000166 etime=0.012879 nentries=0 text= 688224ea.1e633093 0x7fffedffb6c0 conn=1020 op=3 SRCH base="ou=<redacted>,dc=<redacted>,dc=<redacted>" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(&(jpegPhoto=*)(|(mail=<redacted>))))" 688224ea.1e64fd20 0x7fffedffb6c0 conn=1020 op=3 SRCH attr=dn 688224ea.1e65fb45 0x7fffedffb6c0 query template of incoming query = (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 688224ea.1e660563 0x7fffedffb6c0 Entering QC, querystr = (&(objectClass=inetOrgPerson)(&(jpegPhoto=*)(|(mail=<redacted>)))) 688224ea.1e660de7 0x7fffedffb6c0 Lock QC index = 0x555555828190 688224ea.1e6616cf 0x7fffedffb6c0 Not answerable: Unlock QC index=0x555555828190 688224ea.1e66209d 0x7fffedffb6c0 QUERY NOT ANSWERABLE 688224ea.1e6627c3 0x7fffedffb6c0 QUERY CACHEABLE 688224ea.1ed69d89 0x7fffedffb6c0 conn=1020 op=3 SEARCH RESULT tag=101 err=32 qtime=0.000009 etime=0.007587 nentries=0 text= 688224ea.1ef64669 0x7ffff4dfe6c0 conn=1020 op=4 UNBIND 688224ea.1efab72d 0x7fffedffb6c0 conn=1020 fd=30 closed Thread 7 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee7fc6c0 (LWP 136445)] refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392 3392 dnl->delete = ( a->a_numvals == 1 ); (gdb) bt #0 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392 #1 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3367 #2 0x00005555555a6098 in slap_response_play (op=op@entry=0x7fffee7fb610, rs=rs@entry=0x7fffee7fb290) at result.c:573 #3 0x00005555555a7ddd in slap_send_search_entry (op=0x7fffee7fb610, rs=0x7fffee7fb290) at result.c:1078 #4 0x000055555562e007 in mdb_search (op=<optimized out>, rs=<optimized out>) at search.c:1110 #5 0x00007ffff73a6509 in refresh_query (op=0x7fffee7fb610, query=0x7fffd8131830, on=0x55555577c350) at pcache.c:3464 #6 consistency_check (ctx=<optimized out>, arg=0x5555559429a0) at pcache.c:3644 #7 0x00007ffff7f9e09d in ldap_int_thread_pool_wrapper (xpool=0x5555557aed80) at tpool.c:1059 #8 0x00007ffff7d3b86b in ?? () from /usr/lib64/libc.so.6 #9 0x00007ffff7dbc858 in ?? () from /usr/lib64/libc.so.6 (gdb) fr 0 #0 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392 3392 dnl->delete = ( a->a_numvals == 1 ); (gdb) p *dnl $17 = { next = 0x0, dn = { bv_len = 40, bv_val = 0x7fffe403cb70 "uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>" }, delete = 80 'P' } (gdb) p a $10 = (Attribute *) 0x0 (gdb) p ad_queryId $14 = (AttributeDescription *) 0x555555819580 (gdb) p *rs $11 = { sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = { r_entry = 0x7fffe403c5a0, r_attr_flags = 17, r_operational_attrs = 0x0, r_attrs = 0x7fffee7fb320, r_nentries = 0, r_v2ref = 0x0 }, sru_sasl = { r_sasldata = 0x7fffe403c5a0 }, sru_extended = { r_rspoid = 0x7fffe403c5a0 "!", r_rspdata = 0x11 } }, sr_flags = 0 } (gdb) p *rs->sr_entry $12 = { e_id = 33, e_name = { bv_len = 40, bv_val = 0x7fffe403cae0 "uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>" }, e_nname = { bv_len = 40, bv_val = 0x7fffe403cb18 "uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>" }, e_attrs = 0x7fffe403c5f0, e_ocflags = 256, e_bv = { bv_len = 0, bv_val = 0x0 }, e_private = 0x7fffe403c5a0 } (gdb) p *rs->sr_entry->e_attrs $13 = { a_desc = 0x555555781be0, a_vals = 0x7fffe403c7f8, a_nvals = 0x7fffe403c7f8, a_numvals = 1, a_flags = 12, a_next = 0x7fffe403c618 } ``` Looking further I can see that attr_find() can return NULL, however NULL are not verified in refresh_purge() after call to attr_find(). Note that I am using 2.6.8 that includes all the changes from ITS#9966 and I can't find any noticeable changes on that area between 2.6.8. and latest 2.6.9. OpenLDAP is built on gentoo with hardened profile: ``` $ /usr/lib64/openldap/slapd -V @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2025 23:10:57) $ @localhost:/var/tmp/portage/net-nds/openldap-2.6.8-r1/work/openldap-OPENLDAP_REL_ENG_2_6_8-abi_x86_64.amd64/servers/slapd $ /usr/lib64/libc.so.6 -V GNU C Library (Gentoo 2.41-r4 (patchset 6)) stable release version 2.41. Copyright (C) 2025 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 14.3.0. libc ABIs: UNIQUE IFUNC ABSOLUTE Minimum supported kernel: 3.2.0 For bug reporting instructions, please see: <https://bugs.gentoo.org/>. ``` Configuration is as follow: ``` pidfile /run/openldap/slapd.pid argsfile /run/openldap/slapd.args include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc8284.schema # From https://raw.githubusercontent.com/jirutka/ssh-ldap-pubkey/refs/heads/master… include /etc/openldap/schema/openssh-lpk.schema #loglevel stats stats2 loglevel stats # Load dynamic modules moduleload argon2.so moduleload pw-pbkdf2.so moduleload pw-sha2.so moduleload back_sql.so moduleload pcache.so # Transport Layer Security TLSCertificateFile /etc/ssl/ldap/openldap.crt TLSCertificateKeyFile /etc/ssl/ldap/openldap.key TLSProtocolMin 3.4 TLSCipherSuite ECDHE+CHACHA20:ECDHE+AESGCM TLSECName X448:P-384:X25519:P-256 # Default search base to use when client submits a non-base search request with an empty base DN defaultsearchbase dc=<redacted>,dc=<redacted> # Hashes to be used in generation of user passwords password-hash {ARGON2ID} # Specify a set of conditions to require require LDAPv3 strong disallow bind_anon # Set of security strength factors to require security ssf=128 localSSF 256 # SASL security properties sasl-secprops noanonymous,noplain # SASL mapping authz-regexp uid=([^@]+)@([^,]+),cn=login,cn=auth uid=$1,ou=$2,dc=<redacted>,dc=<redacted> authz-regexp uid=([^@]+)@([^,]+),cn=plain,cn=auth uid=$1,ou=$2,dc=<redacted>,dc=<redacted> # Allow access to root over SASL access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * break # Allow service authentication from UNIX socket only access to dn.subtree="dc=local" attrs=userPassword by sockname="PATH=/var/run/ldapi" auth by anonymous auth by * none # Allow access to top level objects access to dn.base="dc=local" by users read by * break # Allow access to service CN access to dn.subtree="dc=local" by set.exact="this/cn & user/cn" read by * break # Allow user authentication access to dn.subtree="dc=<redacted>,dc=<redacted>" attrs=userPassword by anonymous auth by * none # Allow access to top level objects access to dn.base="dc=<redacted>,dc=<redacted>" by users read by * break # Allow access to users OU access to dn.subtree="dc=<redacted>,dc=<redacted>" by set.exact="this/ou & user/ou" read by * break # Allow services to access directory access to dn.subtree="dc=<redacted>,dc=<redacted>" by dn.exact="cn=<redacted>,dc=local" read by dn.exact="cn=<redacted>,dc=local" read by * break # Deny everything else access to * by * none # The config backend manages all of the configuration information for the slapd(8) daemon. database config # Access control policy access to dn.subtree="cn=config" by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # Database instance definition database mdb directory /var/lib/openldap-data/dc=local # DN suffix of queries that will be passed to this backend database suffix dc=local # Database instance definition database sql dbname openldap dbuser openldap dbpasswd <redacted> # DN suffix of queries that will be passed to this backend database suffix dc=<redacted>,dc=<redacted> rootdn "uid=root,dc=<redacted>,dc=<redacted>" # Put the database into "read-only" mode readonly yes subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" children_cond "ldap_entries.dn LIKE CONCAT('%,',?)" dn_match_cond "ldap_entries.dn=?" oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" delentry_stmt "DELETE FROM ldap_entries WHERE id=?" renentry_stmt "UPDATE ldap_entries SET dn=?,parent=?,keyval=? WHERE id=?" delobjclasses_stmt "DELETE FROM ldap_entry_objclasses WHERE entry_id=?" # Do not use DN in reverse uppercased form has_ldapinfo_dn_ru no # Caching of LDAP search requests in a local databas overlay pcache pcache mdb 65536 16 1024 60 directory /var/lib/openldap-data/pcache pcacheMaxQueries 1024 # Cache DN pcacheAttrset 0 1.1 pcacheTemplate (objectClass=) 0 3600 60 0 15 pcacheTemplate (objectClass=*) 0 3600 60 0 15 pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 0 3600 60 0 15 pcacheAttrset 1 jid pcacheTemplate (jid=) 1 3600 60 0 15 pcacheAttrset 2 ou cn givenname sn mail telephonenumber jid description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 2 3600 60 0 15 pcacheTemplate (objectClass=*) 2 3600 60 0 15 pcacheTemplate (objectClass=) 2 3600 60 0 15 pcacheAttrset 3 ou cn givenname sn mail telephonenumber description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 3 3600 60 0 pcacheTemplate (objectClass=*) 3 3600 60 0 pcacheTemplate (objectClass=) 3 3600 60 0 pcacheAttrset 4 mail pcacheTemplate (objectClass=*) 4 3600 60 0 pcacheAttrset 5 * + pcacheTemplate (objectClass=*) 5 3600 60 0 15 pcacheTemplate (mail=) 5 3600 60 0 15 ``` Cheers, Bertrand -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10205] New: SSL handshake blocks forever in async mode if server unaccessible
by openldap-its＠openldap.org 23 Sep '25

23 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10205 Issue ID: 10205 Summary: SSL handshake blocks forever in async mode if server unaccessible Product: OpenLDAP Version: 2.5.17 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: regtube(a)hotmail.com Target Milestone: --- When ldaps:// scheme is used to connect to currently unaccessible server with LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks forever on SSL_connect. Here is a trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP winserv.test.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.56.2:636 ldap_pvt_connect: fd: 3 tm: 30 async: -1 ldap_ndelay_on: 3 attempting to connect: connect errno: 115 ldap_int_poll: fd: 3 tm: 0 ldap_err2string [2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X) [2024-04-25 15:41:27.112] [error] [:1] err: -18 ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 3 tm: 0 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello Looks like it happens because non-blocking mode is cleared from the socket (ldap_ndelay_off) after the first poll for write, and non-blocking mode is never restored before attempt to do tls connect, because of the check that assumes that non-blocking mode has already been set for async mode: if ( !async ) { /* if async, this has already been set */ ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); } while in fact it was cleared. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10386] New: Feature request for Bcrypt Module
by openldap-its＠openldap.org 23 Sep '25

23 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10386 Issue ID: 10386 Summary: Feature request for Bcrypt Module Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: young2k15(a)tutanota.com Target Milestone: --- I would like to have a bcrypt module added to the project. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

08 Sep '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 5

[Issue 10356] New: Openldap -> Chasing the referral is not proceeding further after 3 referrals
by openldap-its＠openldap.org 26 Aug '25

26 Aug '25

https://bugs.openldap.org/show_bug.cgi?id=10356 Issue ID: 10356 Summary: Openldap -> Chasing the referral is not proceeding further after 3 referrals Product: OpenLDAP Version: 2.4.56 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hharshitha2797(a)gmail.com Target Milestone: --- Hi Team I have an issue with OpenLDAP 2.4.56. Chasing the referral only yields 3 referrals; the user login does not proceed further to other referrals. This issue is seen in CentOS with OPENSSL 3.0 In OpenLDAP 2.1.22, the same is working; here, OpenSSL is not used. Here OPENSSL 3.0 is not used. We can see around 8 referrals here. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

26 Aug '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 8

[Issue 10338] New: constraint overlay rejects empty modifications
by openldap-its＠openldap.org 26 Aug '25

26 Aug '25

https://bugs.openldap.org/show_bug.cgi?id=10338 Issue ID: 10338 Summary: constraint overlay rejects empty modifications Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If configured even with no rules, a modification with a NULL op->orm_modlist is rejected, despite not being able to break any constraints, e.g.: dn: cn=example changetype: modify # no modifications attached This should at least be configurable. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10301] New: Use assertion control in lastbind chaining
by openldap-its＠openldap.org 26 Aug '25

26 Aug '25

https://bugs.openldap.org/show_bug.cgi?id=10301 Issue ID: 10301 Summary: Use assertion control in lastbind chaining 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: --- Take a setup with a bunch of consumers tracking lastbind information and replicating this back from the provider. If a client sends a lot of successful binds to it in a very short window, the changes might not have a chance to replicate down so each of these binds has to trigger a new modification to be forwarded. This results in a lot of DB churn and replication traffic that is actually meaningless (the pwdLastChange values before and after each of the mods will be the same). We probably can't avoid having to send something, but the change we send could have an assertion control attached that lets the provider skip it if pwdLastChange>=new_value, saving on all of the additional processing (and additional useless replication traffic). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Bug 9186] New: RFE: More metrics in cn=monitor
by openldap-its＠openldap.org 26 Aug '25

26 Aug '25

https://bugs.openldap.org/show_bug.cgi?id=9186 Bug ID: 9186 Summary: RFE: More metrics in cn=monitor Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Currently I'm grepping metrics from syslog with mtail: https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta… With a new binary logging this is not possible anymore. Thus it would be nice if cn=monitor provides more metrics. 1. Overall connection count per listener starting at 0 when started. This would be a simple counter added to: entries cn=Listener 0,cn=Listeners,cn=Monitor 2. Counter for the various "deferring" messages separated by the reason for deferring. 3. Counters for all possible result codes. In my mtail program I also label it with the result type. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Issue 10092] New: Local logging doesn't build on Windows
by openldap-its＠openldap.org 19 Aug '25

19 Aug '25

https://bugs.openldap.org/show_bug.cgi?id=10092 Issue ID: 10092 Summary: Local logging doesn't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- slapd/logging.c uses writev() to write a prefix and the log message together in one call. This feature doesn't exist on Windows. The closest equivalent, WriteFileGather, only works on page sized and aligned writes. On Windows the only way to write as desired is to copy the message into a new buffer first. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

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 August 2025