openldap-bugs April 2025

openldap-bugs@openldap.org

1 participants
40 discussions

[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=9934 Issue ID: 9934 Summary: slapd-config(5) should document how to store certificates for slapd usage Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Commit 7b41feed83b expanded the ability of cn=config to save the certificates used for TLS by slapd directly in the config database. However the documentation for the new parameters was never added to the slapd-config(5) man page. olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey -- You are receiving this mail because: You are on the CC list for the issue.

1 13

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

20 May '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 6

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

20 May '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 5

[Issue 10297] New: LDAP initialization does unnecessary resolution of hostname
by openldap-its＠openldap.org 14 May '25

14 May '25

https://bugs.openldap.org/show_bug.cgi?id=10297 Issue ID: 10297 Summary: LDAP initialization does unnecessary resolution of hostname Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- curl --version does try to resolve local hostname, which is usually stored in $HOSTNAME variable. It seems it does that for no good reason. It does not matter whether machine hostname is already FQDN or not, it always try it unconditionally by calling getaddrinfo(3). Every usage of dnf tries to resolve hostname. That is then supressed by myhostname on Fedora, which returns non-helping response. Possibly, the hostname should be fetched from actual network responses. Seen with: openldap-2.6.8-5.fc41.x86_64 Reproducible: Always Steps to Reproduce: 1. dnf install gdb curl 2. gdb --args curl --version 3. (gdb) break getaddrinfo 4. (gdb) run Actual Results: getaddrinfo is called with current hostname, stored into ldap_int_hostname variable. That is used only when ldap client has not configured target server. But this hostname seems fetched always. Expected Results: No network activity happens, unless something is actually requested. This is not the case. Suggestion is to make it lazy initialized. It should be tried only when necessary. This seems to be useful when tlso_session_chkhost in libraries/libldap/tls_o.c is used. It should initialize hostname only once conditions to use it happens. There is a fallback anyway. It should query FQDN only when name_in contains unusable response. Related: https://github.com/systemd/systemd/issues/34897 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10304] New: Unable to remove item from directory as part of transaction if it is the last item in that directory
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10304 Issue ID: 10304 Summary: Unable to remove item from directory as part of transaction if it is the last item in that directory Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: sophie.elliott(a)arcticlake.com Target Milestone: --- I am running my ldap server on Debian 11.3, with the mdb backend, using the backported openldap version 2.5.13. I am not 100% certain if this is an issue with OpenLDAP or liblmdb, but I have been running tests in the repo and it looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself. I have been performing a transaction, and deleting entries from a directory during this transaction. This works fine if the item that I am deleting isn't the last entry in its directory, but when it is I get a MDB_NOTFOUND error on the commit transaction call and the delete doesn't go through. Here is an excerpt of the logs when this happens: ``` 67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) 67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624] 67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) success 67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND: No matching key/data pair found (-30798) ``` Please let me know if I should submit this issue elsewhere, or if this is something that has already been fixed in a more recent version. I'm also happy to provide more details if necessary. Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10332] New: Add support for SSLKEYLOGFILE environment variable to export keys for Wireshark decryption
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10332 Issue ID: 10332 Summary: Add support for SSLKEYLOGFILE environment variable to export keys for Wireshark decryption Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael.osipov(a)siemens.com Target Milestone: --- Please add support to do the following: SSLKEYLOGFILE=keylog.txt ldapsearch -H ldaps://... Other libraries and tools support it to decrypt the TLS traffic with Wireshark for analysis purposes. Curl has a simple, but complete implementation: https://github.com/curl/curl/blob/e008f71f435a39875d86885a96b2eb8968a60fd4/… Maybe it can be reused if license allows that?! -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10321] New: slapd garbles userCertificate hex code
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=10321 Issue ID: 10321 Summary: slapd garbles userCertificate hex code Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: jnabasny(a)gmail.com Target Milestone: --- I discovered an issue with how slapd handles hex encoded userCertificate;binary values while testing identical setups between FreeIPA and OpenLDAP. It seems to partially decode the hex, causing any search to fail. This was discovered when using SSSD, but is reproducible with ldapsearch. Essentially, you run a query like this using the hex encoded value of the certificate: ldapsearch -H ldap://10.10.0.94 -D cn=admin,dc=nabasny,dc=com -b "dc=nabasny,dc=com" -W '(&(userCertificate;binary=\30\82\04\85\30\82\02\ed\a0\03\02\01\02\02\01\0d\30\0d\06\09\2a\86\48\86\f7\0d\01\01\0b\05\00\30\37\31\15\30\13\06\03\55\04\0a\0c\0c\46\52\45\45\49\50\41\2e\48\4f\4d\45\31\1e\30\1c\06\03\55\04\03\0c\15\43\65\72\74\69\66\69\63\61\74\65\20\41\75\74\68\6f\72\69\74\79\30\1e\17\0d\32\35\30\33\32\30\31\35\34\35\32\36\5a\17\0d\32\37\30\33\32\31\31\35\34\35\32\36\5a\30\26\31\15\30\13\06\03\55\04\0a\0c\0c\46\52\45\45\49\50\41\2e\48\4f\4d\45\31\0d\30\0b\06\03\55\04\03\0c\04\6a\61\6b\65\30\82\01\22\30\0d\06\09\2a\86\48\86\f7\0d\01\01\01\05\00\03\82\01\0f\00\30\82\01\0a\02\82\01\01\00\b9\b2\3b\be\d1\20\bd\f2\ba\69\e6\b6\e5\2d\13\b0\77\a6\59\69\50\76\4c\07\71\ce\ee\8f\41\ef\04\20\1b\8e\a5\f7\8a\96\0d\f1\89\a5\84\cd\2f\be\ff\9c\2a\b2\bf\99\20\ca\ae\fc\a2\16\df\40\5b\d4\5e\7b\51\a5\b0\dd\bc\e9\c4\b1\e7\89\7c\25\f2\4b\b0\08\09\bd\60\58\c1\8f\af\fb\2a\5e\90\69\37\27\40\61\62\bb\7a\b8\76\18\11\96\2e\45\54\26\b0\c7\ec\92\3c\72\90\52\1a\44\0f\69\5c\b4\f1\98\53\4e\15\86\33\1a\81\ee\70\63\ae\e4\c7\32\7f\92\14\71\9d\58\c0\7d\a1\20\dc\f5\f6\47\29\45\56\bd\a2\dd\eb\4a\17\f2\2a\72\6f\fd\0f\a3\7e\a0\96\de\02\f3\b2\d9\ac\fc\af\38\c9\7a\21\c3\1b\19\4c\bc\d8\11\48\22\cf\18\ec\17\85\51\e9\51\22\49\aa\89\1a\73\2b\8d\40\e9\a9\3a\dd\e8\6e\9b\27\45\09\fd\a4\88\f5\7c\4e\96\b7\82\cd\f6\e2\1e\08\53\38\af\f9\4d\55\9c\79\0f\32\d8\bb\85\83\08\c0\b9\f3\39\7f\b9\7b\a9\02\03\01\00\01\a3\82\01\2b\30\82\01\27\30\1f\06\03\55\1d\23\04\18\30\16\80\14\0d\6b\b6\82\13\0c\a2\9d\91\01\40\e8\59\d6\2b\ec\87\1a\f0\36\30\3e\06\08\2b\06\01\05\05\07\01\01\04\32\30\30\30\2e\06\08\2b\06\01\05\05\07\30\01\86\22\68\74\74\70\3a\2f\2f\69\70\61\2d\63\61\2e\66\72\65\65\69\70\61\2e\68\6f\6d\65\2f\63\61\2f\6f\63\73\70\30\0e\06\03\55\1d\0f\01\01\ff\04\04\03\02\04\f0\30\1c\06\03\55\1d\25\04\15\30\13\06\08\2b\06\01\05\05\07\03\01\06\07\2b\06\01\05\02\03\05\30\77\06\03\55\1d\1f\04\70\30\6e\30\6c\a0\34\a0\32\86\30\68\74\74\70\3a\2f\2f\69\70\61\2d\63\61\2e\66\72\65\65\69\70\61\2e\68\6f\6d\65\2f\69\70\61\2f\63\72\6c\2f\4d\61\73\74\65\72\43\52\4c\2e\62\69\6e\a2\34\a4\32\30\30\31\0e\30\0c\06\03\55\04\0a\0c\05\69\70\61\63\61\31\1e\30\1c\06\03\55\04\03\0c\15\43\65\72\74\69\66\69\63\61\74\65\20\41\75\74\68\6f\72\69\74\79\30\1d\06\03\55\1d\0e\04\16\04\14\e8\11\4b\36\86\c9\7c\a2\d7\4e\ff\7c\13\89\2b\38\8d\c4\ec\32\30\0d\06\09\2a\86\48\86\f7\0d\01\01\0b\05\00\03\82\01\81\00\58\af\2b\7e\fd\05\b9\46\8a\c7\b9\e4\96\42\47\2d\8f\17\01\8e\58\30\95\9c\be\e7\2d\a8\22\64\5e\fd\f5\ec\46\97\2d\88\bc\06\b0\e7\a3\77\a3\d0\b6\da\01\4f\73\f4\3d\c9\47\49\e2\d0\a0\e8\bd\a9\62\fd\6c\de\81\32\9a\33\d5\58\57\d8\c9\47\54\78\fa\69\20\49\11\c9\dc\4f\f4\bc\37\63\28\6a\fd\e2\f7\4b\0f\44\26\90\6c\22\c9\b8\ff\9a\36\05\a3\24\3c\58\73\6f\4b\17\2d\e3\22\30\aa\34\4e\2f\36\24\94\6a\24\9b\bf\ac\e5\23\33\f6\3f\cf\c7\dd\38\91\85\63\c0\61\55\5f\de\2b\e6\3d\13\4f\8c\6a\6a\1e\3b\0e\4a\8c\e9\c3\46\ef\02\bb\63\b7\09\9f\d8\5c\67\4c\c6\40\8f\1e\7e\c8\f0\89\4c\8f\f8\24\63\42\31\f9\5d\5b\2d\cb\78\c3\94\5f\3e\ca\b8\7b\68\9a\6a\09\0c\22\bd\da\39\9f\b7\0f\4f\20\a9\1a\de\d7\8a\31\af\a3\ac\14\d1\ba\90\b8\22\56\31\b1\52\78\73\6f\36\05\88\0b\56\31\fd\55\89\7d\55\8b\01\1d\58\0c\75\03\bd\7c\7b\05\c7\86\15\90\0c\f4\c6\91\d3\f6\73\e9\8f\1f\25\88\32\b2\cb\53\db\91\e4\8b\28\a1\22\7a\38\ac\f5\8b\32\51\d4\9e\d6\e1\15\0d\fb\8f\60\09\e5\0c\dd\d4\19\fe\f7\44\cd\ac\ff\82\94\16\f5\7d\19\57\30\79\96\4b\7b\61\d0\b8\c3\0c\1c\2f\89\7e\01\5e\a0\95\9a\aa\d3\e2\6d\d5\fa\2e\e8\57\5a\b3\45\23\17\40\c9\d3\92\9e\11\cc\c4\31\f2\e5\94\e3\8f\5e\d9\51\92\cd\46\77\33\c8\4b\50\84\73)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))' And slapd logs the query as: Mar 20 19:54:01 ldap slapd[457]: conn=1058 op=3 SRCH base="ou=people,dc=nabasny,dc=com" scope=2 deref=0 filter="(&(?userCertificate;binary=0\82\04\850\82\02\ED\A0\03\02\01\02\02\01\0D0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\00071\150\13\06\03U\04\0A\0C\0CFREEIPA.HOME1\1E0\1C\06\03U\04\03\0C\15Certificate Authority0\1E\17\0D250320154526Z\17\0D270321154526Z0&1\150\13\06\03U\04\0A\0C\0CFREEIPA.HOME1\0D0\0B\06\03U\04\03\0C\04jake0\82\01"0\0D\06\09\2A\86H\86\F7\0D\01\01\01\05\00\03\82\01\0F\000\82\01\0A\02\82\01\01\00\B9\B2;\BE\D1 \BD\F2\BAi\E6\B6\E5-\13\B0w\A6YiPvL\07q\CE\EE\8FA\EF\04 \1B\8E\A5\F7\8A\96\0D\F1\89\A5\84\CD/\BE\FF\9C\2A\B2\BF\99 \CA\AE\FC\A2\16\DF@[\D4^{Q\A5\B0\DD\BC\E9\C4\B1\E7\89|%\F2K\B0\08\09\BD`X\C1\8F\AF\FB\2A^\90i7'@ab\BBz\B8v\18\11\96.ET&\B0\C7\EC\92<r\90R\1AD\0Fi\5C\B4\F1\98SN\15\863\1A\81\EEpc\AE\E4\C72\7F\92\14q\9DX\C0}\A1 \DC\F5\F6G\29EV\BD\A2\DD\EBJ\17\F2\2Aro\FD\0F\A3~\A0\96\DE\02\F3\B2\D9\AC\FC\AF8\C9z!\C3\1B\19L\BC\D8\11H"\CF\18\EC\17\85Q\E9Q"I\AA\89\1As+\8D@\E9\A9:\DD\E8n\9B'E\09\FD\A4\88\F5|N\96\B7\82\CD\F6\E2\1E\08S8\AF\F9MU\9Cy\0F2\D8\BB\85\83\08\C0\B9\F39\7F\B9{\A9\02\03\01\00\01\A3\82\01+0\82\01'0\1F\06\03U\1D#\04\180\16\80\14\0Dk\B6\82\13\0C\A2\9D\91\01@\E8Y\D6+\EC\87\1A\F060>\06\08+\06\01\05\05\07\01\01\042000.\06\08+\06\01\05\05\070\01\86"http://ipa-ca.freeipa.home/ca/ocsp0\0E\06\03U\1D\0F\01\01\FF\04\04\03\02\04… Authority0\1D\06\03U\1D\0E\04\16\04\14\E8\11K6\86\C9|\A2\D7N\FF|\13\89+8\8D\C4\EC20\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\00\03\82\01\81\00X\AF+~\FD\05\B9F\8A\C7\B9\E4\96BG-\8F\17\01\8EX0\95\9C\BE\E7-\A8"d^\FD\F5\ECF\97-\88\BC\06\B0\E7\A3w\A3\D0\B6\DA\01Os\F4=\C9GI\E2\D0\A0\E8\BD\A9b\FDl\DE\812\9A3\D5XW\D8\C9GTx\FAi I\11\C9\DCO\F4\BC7c\28j\FD\E2\F7K\0FD&\90l"\C9\B8\FF\9A6\05\A3$<XsoK\17-\E3"0\AA4N/6$\94j$\9B\BF\AC\E5#3\F6?\CF\C7\DD8\91\85c\C0aU_\DE+\E6=\13O\8Cjj\1E;\0EJ\8C\E9\C3F\EF\02\BBc\B7\09\9F\D8\5CgL\C6@\8F\1E~\C8\F0\89L\8F\F8$cB1\F9][-\CBx\C3\94_>\CA\B8{h\9Aj\09\0C"\BD\DA9\9F\B7\0FO \A9\1A\DE\D7\8A1\AF\A3\AC\14\D1\BA\90\B8"V1\B1Rxso6\05\88\0BV1\FDU\89}U\8B\01\1DX\0Cu\03\BD|{\05\C7\86\15\90\0C\F4\C6\91\D3\F6s\E9\8F\1F%\882\B2\CBS\DB\91\E4\8B\28\A1"z8\AC\F5\8B2Q\D4\9E\D6\E1\15\0D\FB\8F`\09\E5\0C\DD\D4\19\FE\F7D\CD\AC\FF\82\94\16\F5}\19W0y\96K{a\D0\B8\C3\0C\1C/\89~\01^\A0\95\9A\AA\D3\E2m\D5\FA.\E8WZ\B3E#\17@\C9\D3\92\9E\11\CC\C41\F2\E5\94\E3\8F^\D9Q\92\CDFw3\C8KP\84s)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))" Some of the hex has been decoded into readable strings, which causes the search to fail. Running the same search on FreeIPA with an identical user entry returns the entry correctly. I'm happy to provide more logs/details if needed. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

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

06 May '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 5

[Issue 10163] New: Cleanup configure/test integration
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=10163 Issue ID: 10163 Summary: Cleanup configure/test integration Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The sed commandline configure uses to perform substitutions is getting unwieldy and may be exceeding platform limits on various systems. All of the BUILD_xxx substitutions for overlays are only used in tests/run.in. They could be completely removed, and instead each of the enabled overlays could be emitted into a separate file that just gets included by the test scripts. There's no need for them to be part of the sed invocation at all. There's also leftover BUILD_xxx cruft from backends that we've removed (e.g. back-shell BUILD_SHELL) that nothing else in the tree references any more. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9367] New: back-mdb: encryption support
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=9367 Issue ID: 9367 Summary: back-mdb: encryption support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to add encryption support to the back-mdb backend, depends on issue#9364 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2025