openldap-bugs April 2025

openldap-bugs@openldap.org

1 participants
32 discussions

[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 10329] New: Additional issues with pcache, and a test
by openldap-its＠openldap.org 13 May '25

13 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 5

[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 10140] New: Add microsecond timestamp format for local file logging
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=10140 Issue ID: 10140 Summary: Add microsecond timestamp format for local file logging 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: gnoe(a)symas.com Target Milestone: --- Add microsecond-level timestamps to local file logging. Format is: "YYYY-mm-ddTHH:MM:SS.ffffffZ" The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Gregory Noe gnoe(a)symas.com. I have not assigned rights and/or interest in this work to any party. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2023 Gregory Noe Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

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

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

[Issue 10328] New: Possible multiple free() calls in rewrite_subst_compile()
by openldap-its＠openldap.org 06 May '25

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

[Issue 10327] New: Adding syncprov to cn=config can lock up server
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=10327 Issue ID: 10327 Summary: Adding syncprov to cn=config can lock up server Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- As reported on openldap-technical[0], adding syncprov to a cn=config DB can lock up the server. This happens when syncprov_db_otask is scheduled by syncprov_db_open. ITS#9045 has already dealt with this for config_back_entry_get, we can relax this description and allow a config_back_search do the same. Even though it is technically on a different thread than the main modification, AFAIK it is still the only one running as the server is paused and the main modification is paused waiting for it? [0]. 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 4

[Issue 10325] New: Variant uses overlays OID instead of contrib OID (OLcfgOvAt instead of OLcfgCtAt) for configuration attributes
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=10325 Issue ID: 10325 Summary: Variant uses overlays OID instead of contrib OID (OLcfgOvAt instead of OLcfgCtAt) for configuration attributes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The variant contrib overlay uses the wrong base OID for its attributes, which leads to OID duplication with DDS -- You are receiving this mail because: You are on the CC list for the issue.

1 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2025