openldap-bugs September 2025

openldap-bugs@openldap.org

1 participants
49 discussions

[Issue 10394] New: remove stroeder.com from support page
by openldap-its＠openldap.org 23 Sep '25

23 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10394 Issue ID: 10394 Summary: remove stroeder.com from support page Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- HI! for health reasons I gave up my business and I have retired . So it does no longer make sense to be listed on the support page. Ciao, Michael. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

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

18 Sep '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 4

[Issue 10361] New: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes
by openldap-its＠openldap.org 18 Sep '25

18 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10361 Issue ID: 10361 Summary: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: a.cudbardb(a)freeradius.org Target Milestone: --- Created attachment 1081 --> https://bugs.openldap.org/attachment.cgi?id=1081&action=edit Patch adding olcAuditlogNonBlocking and a tests for slapo-auditlog The default behaviour of fopen() when called on a named pipe which does not have any reader, is to block, until a reader opens the pipe. This in turn blocks slapo-auditlog when it attempts to write output, and prevents slapd processing requests. Depending on how critical the audit log is, it may be preferable to discard audit log output and continue processing requests if there's no reader available which olcAuditLogNonBlocking: TRUE allows. For clarity the call to fopen() is removed and replaced with open()/fdopen(), allowing us to specify O_* flags as opposed to using fopen() OR open()/fdopen() depending on whether we should block. 0666 are the base permissions used by fopen() when files are created. There were no tests for slapo-auditlog, so a small test suite that tests both the basic behaviour, and blocking/non-blocking writes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10385] New: syncprov should use accesslog's rootDN when reading it
by openldap-its＠openldap.org 17 Sep '25

17 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10385 Issue ID: 10385 Summary: syncprov should use accesslog's rootDN when reading it 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: --- When replaying accesslog, syncprov runs a be_search, it should switch to using the appropriate rootDN for the database. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10387] New: Reverse lookup does not work for IPv6 addresses proxied over IPv4
by openldap-its＠openldap.org 17 Sep '25

17 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10387 Issue ID: 10387 Summary: Reverse lookup does not work for IPv6 addresses proxied over IPv4 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: +openldap(a)Eero.xn--Hkkinen-5wa.fi Target Milestone: --- I have an IPv4/IPv6 reverse proxy server which listens for ldap[s]:// connections and forwards them using the proxy procotol to an IPv4-only slapd server which listens for pldap[s]:// connections. The slapd server has the global olcReverseLookup setting set to TRUE. The reverse lookup works as expected if an LDAP client connects to the reverse proxy using IPv4. However, if the LDAP client connects to the reverse proxy using IPv6, the reverse lookup does not work. The slap_listener function in the servers/slapd/daemon.c file accepts a connection (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…). Because the reverse proxy connects to the slapd server using the proxy protocol over IPv4, this fills the from variable with an IPv4 address and sets the len variable to the size of the struct sockaddr_in. This is correct. The slap_listener function detects that the connection is proxied (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) and uses the proxyp function to get the address of the LDAP client. This fills the from variable with an IPv4 or an IPv6 address (depending on whether the LDAP client used IPv4 or IPv6 to connect the reverse proxy) but does not update the len variable. The slap_listener function detects that reverse lookup is to be used (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) and used the ldap_pvt_get_hname function to get the reverse name (https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_10/s…) passing the address of the from variable, which may contain either an IPv4 or an IPv6 address, and the value of the len variable, which is equal to the size of the struct sockaddr_in. This is correct for IPv4 but not for IPv6. Either the slap_listener function or the proxyp function should update the value of the len variable. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10360] New: delta-sync can apply old mods
by openldap-its＠openldap.org 17 Sep '25

17 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10360 Issue ID: 10360 Summary: delta-sync can apply old mods Product: OpenLDAP Version: 2.6.9 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: --- This might be related to #10358, but not sure. In delta MPR, if an older mod is received on an entry after a newer mod has already been applied by a local user, the older mod is applied and the newer mod is lost. The incoming replication ops are checked for freshness by check_csn_age() but that only checks the incoming cookieCSN against contextCSNs of the same SID. I.e., that check only prevents duplicate mods being replicated multiple times from the same remote provider. If check_csn_age() passes, then syncrepl_message_to_op() is invoked which just applies the mod. It doesn't check the mod or cookieCSN against the entry's current entryCSN. The code in syncrepl_op_mod() performs the checks we need. The code just needs to be pulled into a new function so it can be used in both places. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10388] New: ldif_parse_line2 is not compliant with RFC2849
by openldap-its＠openldap.org 17 Sep '25

17 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10388 Issue ID: 10388 Summary: ldif_parse_line2 is not compliant with RFC2849 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- RFC2849: Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F ; any value <= 127 except NUL, LF, CR, ; SPACE, colon (":", ASCII 58 decimal) ; and less-than ("<" , ASCII 60 decimal) However, if the value is not base64 encoded, ldif_parse_line2 (and consequently ldap_parse_ldif_record_x) uses isspace() to just skip any white-space characters at the beginning of at attribute value, icl. tabs. According to the RFC, however, such characters are acceptable. In addition, it does not return an error on LF or CR, just skips them. On the one hand, LDIFs are supposed to be human readable, and fixing this issue may lead to unexpected problems (e.g a stray tab being added to the attribute value). On the other hand, the standard does not exclude %x01-09 and %x0B-0C as valid characters for a non-encoded value. How should we proceed? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10383] New: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it
by openldap-its＠openldap.org 17 Sep '25

17 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10383 Issue ID: 10383 Summary: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.frickert(a)protonmail.com Target Milestone: --- Hi, We are using slapd-meta to connect an OpenLDAP server to another external LDAP server and it works well on first configuration. However, if we want to update any info, e.g. the external LDAP URI, we must replace the olcDbURI attribute. This means that the ordering of the attributes change and this attribute is now defined after olcDbIDAssertBind. Didn't think this would be important, but after this change the "meta" connection stops working and upon enabling debugging i can see that the external LDAP server is responding with: "ldap_bind: Inappropriate authentication (48) additional info: Anonymous Simple Bind Disabled" This seems to imply that the olcDbIDAssertBind attribute is being ignored, likely due to being defined before olcDbURI (my assumption). Is this intended? If so, what can we do to mitigate this problem? Do we need to perform a replace on all attributes of the object to ensure correct ordering, or is there any way to perform an in-place attribute modification without making it shift its position in the object? Example: First configuration (OK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri --> olcDbURI: ldap://REDACTED/ou=users,REDACTED olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon After URI update (NOK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon --> olcDbURI: ldap://REDACTED/ou=users,REDACTED The olcDbURI attribute is shifted to the bottom after a modify operation, and seems to cause these issues. Best Regards, David -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10390] New: ldif_parse_line2 calculates an incorrect length of the attribute type
by openldap-its＠openldap.org 16 Sep '25

16 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10390 Issue ID: 10390 Summary: ldif_parse_line2 calculates an incorrect length of the attribute type Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- When parsing a line containing an attribute name and a value, e.g "carLicence : 12344", ldif_parse_line2 calculates the type length incorrectly. It is not clear if this affects any existing code or tools at the moment, but should be fixed. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10358] New: syncrepl can revert an entry's CSN
by openldap-its＠openldap.org 11 Sep '25

11 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10358 Issue ID: 10358 Summary: syncrepl can revert an entry's CSN 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: --- Created attachment 1080 --> https://bugs.openldap.org/attachment.cgi?id=1080&action=edit Debug log of an instance of this happening There is a sequence of operations which can force a MPR node to apply changes out of order (essentially reverting an operation). Currently investigating which part of the code that should have prevented this has let it slip. A sample log showing how this happened is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2025