openldap-bugs October 2025

openldap-bugs@openldap.org

1 participants
18 discussions

[Issue 10396] New: LMDB: another issue with sorted duplicate DBs and cursor delete
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10396 Issue ID: 10396 Summary: LMDB: another issue with sorted duplicate DBs and cursor delete Product: LMDB Version: 0.9.19 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- In mdb_cursor_del0, in the second "Adjust other cursors" section (after mdb_rebalance was called), in these lines if (m3->mc_xcursor && !(m3->mc_flags & C_EOF)) { MDB_node *node = NODEPTR(m3->mc_pg[m3->mc_top], m3->mc_ki[m3->mc_top]); The node being referenced should be using mc->mc_top, not m3->mc_top. Most of the time these will be identical, but sometimes due to rebalancing, the mc cursor may be popped below its stack top when calling here. This bug was introduced for ITS#8406 in commit 37081325f7356587c5e6ce4c1f36c3b303fa718c on 2016-04-18. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10392] New: back-ldap does not return a response if incorrect secprops is configured
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10392 Issue ID: 10392 Summary: back-ldap does not return a response if incorrect secprops is configured Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- If a non-existent secprops mechanism is configured as part of a back-ldap idassert-bind directive, back-ldap does not return a response to the following requests, leaving the client waiting. In the same case meta and asyncmeta would return an LDAP error. My guess is failure to establish the target connection is handled incorrectly in that code path. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10381] New: Logformat config is broken
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10381 Issue ID: 10381 Summary: Logformat config is broken Product: OpenLDAP Version: 2.6.10 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: --- After ITS#10140, logformat config parsing and emitting is broken. Some formats don't emit in cn=config, some abort. On Windows, log prefix is corrupted. Patch is being tested. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10191 Issue ID: 10191 Summary: backend searches should respond to pause requests Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- A long running search will cause mods to cn=config to wait a long time. Search ops should periodically check for threadpool pause requests. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10393] New: Duplicate test names test090-asyncmeta-conttl and test090-auditlog
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10393 Issue ID: 10393 Summary: Duplicate test names test090-asyncmeta-conttl and test090-auditlog Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Probably patch approval timing problem, I suggest to rename test090-asyncmeta-conttl to test091-asyncmeta-conttl. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10372] New: support lastbind_forward_updates outside of the lastbind overlay
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10372 Issue ID: 10372 Summary: support lastbind_forward_updates outside of the lastbind overlay Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lklement(a)symas.com Target Milestone: --- according to the documentation for the LastBind overlay (slapo-lastbind) this overlay is no longer recommended unless lastbind_forward_updates is used. Can this functionality be added to the current lastbind configuration recommendation? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10313] New: 3-way multimaster oathHOTPCounter attribute update code missing
by openldap-its＠openldap.org 09 Oct '25

09 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10313 Issue ID: 10313 Summary: 3-way multimaster oathHOTPCounter attribute update code missing Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: agrru01(a)gmail.com Target Milestone: --- I posted on openldap technical mail list and got a response saying I should file a feature request. I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My problem is that when authenticating with a user using HOTP, the attribute oathHOTPCounter only updates the value on the target ldap instance. This means the other two ldap instances do not get the updated HOTP-counter value and therefore will allow authentication using the same HOTP code. Interestingly enough, if I manually edit the oathHOTPCounter value it synchronizes with the other masters. Please see the technical mail list discussion: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10397] New: Presence of "auditContext" in root database entry can break replication
by openldap-its＠openldap.org 07 Oct '25

07 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10397 Issue ID: 10397 Summary: Presence of "auditContext" in root database entry can break replication Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When bootstrapping a new environment, I found that the: "auditContext: cn=accesslog" attribute that is added on a provider breaks replication when attempting to replicate to a consumer that has no database present and lacks the accesslog overlay, since that is what defines the attribute in question. Instead we get a corrupted entry with an inability to write to the local database. -- 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 October 2025