- openldap-bugs - openldap.org

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

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

[Issue 10323] New: Starttls critical not working on lloadd
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10323 Issue ID: 10323 Summary: Starttls critical not working on lloadd Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: grichier(a)scaleway.com Target Milestone: --- Hello, Looks like starttls critical not working on lloadd. I have a backend with starttls configure but with bad CN. When I direct query the backend using ldapsearch with option -ZZ, I have the following error: ldap_start_tls: Connect error (-11) additional info: (unknown error code) But when I query the lloadd, which use same backend with olcBkLloadStartTLS to critical. It's work... On a tcpdump I can see the communication between backend and lloadd is not using starttls. (cleartext). But it shouldn't (critical option) cn: {1}ldap://ldap01.example.com olcBkLloadBackendUri: ldap://ldap01.example.com olcBkLloadNumconns: 10 olcBkLloadBindconns: 5 olcBkLloadRetry: 5000 olcBkLloadMaxPendingOps: 50 olcBkLloadMaxPendingConns: 10 olcBkLloadWeight: 1 olcBkLloadStartTLS: critical -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10226] New: [PATCH] ldap.conf: some remarks and editorial fixes for this man page
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10226 Issue ID: 10226 Summary: [PATCH] ldap.conf: some remarks and editorial fixes for this man page Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: bjarniig(a)vortex.is Target Milestone: --- Created attachment 1020 --> https://bugs.openldap.org/attachment.cgi?id=1020&action=edit Remarks and editotiral fixes for the manual ldap.conf.5 Version 2.6.8 is not named on the webpage when entering an issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

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

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

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

23 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 6

[Issue 10270] New: Issues with pcache when refresh/persistPcache used
by openldap-its＠openldap.org 23 May '25

23 May '25

https://bugs.openldap.org/show_bug.cgi?id=10270 Issue ID: 10270 Summary: Issues with pcache when refresh/persistPcache used Product: OpenLDAP Version: 2.5.18 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: --- Greetings, OpenLDAP-folk. We've been running with the pcache overlay in 2.5.18 with both query refresh and pcachePersist for a bit and have observed some oddities: 1.) Negative queries don't get refreshed 2.) Queries don't seem to be persisted These behaviors are all exhibited from the current git version as well - code/patches below for clarity of communication: Thanks! Andy commit c0b4fe92c8df746c0e6a777f93f1687135114eb9 Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:43:47 2024 -0400 negative cache entries are not loaded when pcachePersist is on diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 9ef78fd6bf43..9fd72e6d7261 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -802,7 +802,11 @@ url2query( goto error; } - cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 ); + if (BER_BVISNULL( &uuid )) { + cq = add_query( op, qm, &query, qt, PC_NEGATIVE, 0 ); + } else { + cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 ); + } if ( cq != NULL ) { cq->expiry_time = expiry_time; cq->refresh_time = refresh_time; commit 8f7b50dfcec69fa01f8cf0a4b77f3dee8ef9f0f6 Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:38:36 2024 -0400 queries with ttr/x-refresh are not loaded when pcachePersist is on diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 40c1f9673776..9ef78fd6bf43 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -749,7 +749,7 @@ url2query( } } - if ( got != GOT_ALL ) { + if ( (got & GOT_ALL) != GOT_ALL) { rc = 1; goto error; } commit c7e52c90192a43876d40b9776a58db951d27937c Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:37:13 2024 -0400 ttr was not being applied to negatively cached entries diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 1d6e4ba4edcf..40c1f9673776 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -1580,6 +1580,8 @@ add_query( case PC_NEGATIVE: ttl = templ->negttl; + if ( templ->ttr ) + ttr = now + templ->ttr; break; case PC_SIZELIMIT: -- You are receiving this mail because: You are on the CC list for the issue.

1 7

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

23 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 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 10337] New: Global TLS options not inherited in context
by openldap-its＠openldap.org 20 May '25

20 May '25

https://bugs.openldap.org/show_bug.cgi?id=10337 Issue ID: 10337 Summary: Global TLS options not inherited in context 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: remi(a)fedoraproject.org Target Milestone: --- During ldap_create, global options are copied See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/… /* copy the global options */ AC_MEMCPY(&ld->ld_options, gopts, sizeof(ld->ld_options)); But not the TLS string options See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/… /* We explicitly inherit the SSL_CTX, don't need the names/paths. Leave * them empty to allow new SSL_CTX's to be created from scratch. */ memset( &ld->ld_options.ldo_tls_info, 0, sizeof( ld->ld_options.ldo_tls_info )); ld->ld_options.ldo_tls_ctx = NULL; Which create inconsistency when trying to generate a newctx For the context See * https://github.com/php/php-src/issues/17776 => why tls_newctx is needed * https://github.com/php/php-src/issues/18529 => regression On PHP side a possible workaround is to do the copyu manually * https://github.com/php/php-src/pull/18547 But should probably be handled at openldap library -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[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 10333] New: Recurring crash in lmdb:mdb_page_alloc()
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10333 Issue ID: 10333 Summary: Recurring crash in lmdb:mdb_page_alloc() Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: captgol2000(a)yahoo.com Target Milestone: --- Full_Name: Version: 0.9.29 OS: Vendor built Linux based on Ubuntu kernel 4.14.173 mdb_page_alloc (SIGBUS) Number of Events: 610 We have seen a recurring crash in lmdb:mdb_page_alloc() but only in the field with our product. One instance yielded a core in which we confirmed the same stack back trace when examined. It matches the automated backtrace reports we received from field deployments. The lmdb is built from source at version 0.9.29, unchanged from upstream. The operating environment is an embedded Linux appliance with Linux kernel at version "linux-4.14.173-aum-01" and our own application that uses lmdb to store certain data while transactions are in progress. We build everything with gcc 7.3.0 and link with glibc version 2.27. Unfortunately no in-house reproduction has been possible, only a number of matching stack traces from field reports of application crashes. We are working on some system tests to see if can can cause a reproduction. This report is in hopes some others may have seen a similar backtrace to help locate a bug. (gdb) where #0 mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7ffec216d120, mc=<optimized out>) at mdb.c:2310 #1 0x00007fa2508c764e in mdb_page_new (mc=mc@entry=0x7ffec216d670, flags=flags@entry=1, num=num@entry=1, mp=mp@entry=0x7ffec216d1d0) at mdb.c:7193 #2 0x00007fa2508c7a9b in mdb_page_split (mc=mc@entry=0x7ffec216d670, newkey=newkey@entry=0x7ffec216da70, newdata=newdata@entry=0x7ffec216da50, newpgno=newpgno@entry=18446744073709551615, nflags=0) at mdb.c:8649 #3 0x00007fa2508ca4ee in mdb_cursor_put (mc=0x7ffec216d670, key=0x7ffec216da70, data=0x7ffec216da50, flags=<optimized out>) at mdb.c:6957 #4 0x00007fa2508cc26a in mdb_put (txn=0xb767020, dbi=3, key=0x7ffec216da70, data=0x7ffec216da50, flags=0) at mdb.c:9045 #5 0x00007fa2520a69f4 in XXX_XXX_store::add (this=0x7fa25230ada0 <XXX_x509_validation_s::kv_store_h>, key=0x7ffec216dbc0 "\351\066\030\201\261\223\025\\q\006\204g:\274\241\330\377Ã ", keylen=20, value=0x7ffec216db20 "\002", valuelen=19, flag=<optimized out>, table=XXX_KV_STORE_TABLE_MAIN) at lib/XXX_kv_store.cpp:479 #6 0x00007fa2520a03fa in ?? () #7 0x00007ffec216dc60 in ?? () #8 0x00007ffec216dca8 in ?? () #9 0x00007ffec216dc60 in ?? () #10 0x00007fa2520a2990 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[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 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=7901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.11 Keywords|needs_review | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10334] New: When there is no entry in ldap db getting success response instead of noSuchObject
by openldap-its＠openldap.org 13 May '25

13 May '25

https://bugs.openldap.org/show_bug.cgi?id=10334 Issue ID: 10334 Summary: When there is no entry in ldap db getting success response instead of noSuchObject Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: niranjan.ganjikunta(a)ericsson.com Target Milestone: --- Created attachment 1065 --> https://bugs.openldap.org/attachment.cgi?id=1065&action=edit noSuchobject overlay module Hi Team, We are hosting an LDAP server on an Ubuntu Linux system, and our requirement is to return a noSuchObject error in the LDAP response when a search yields no results, instead of returning a success response. we are using below search command. ldapsearch -b "ou=Subscribers,ou=sda,o=centertel.pl" -D "cn=admin" -w "XXXXX" -H ldap://ip:389 -v -s sub "ptkSubscriberIMSI=26003123456789" This command is trying to search for the imsi under the base dn by using the filter. in this case if there is no entry present in db we are expecting noSuchObject (32) response from ldap. We tried to build overlay by using below c++ script to modify the default ldap behaviour to get nosuchobject when there is no entry in db. #include "portable.h" // Required for OpenLDAP build environment #include <stdio.h> #include <ac/string.h> // OpenLDAP-specific replacements #include <ac/regex.h> // Brings in regex_t, regmatch_t #include <ldap.h> #include "slap.h" #include <stdio.h> #include <ldap.h> #include <slap.h> int my_overlay_search(Operation *op, SlapReply *rs) { // Correct call to next overlay/backend int rc = overlay_op_walk(op, rs, SLAP_OP_SEARCH, (slap_overinfo *)op->o_bd->bd_info, NULL); if (rs->sr_err == LDAP_SUCCESS && rs->sr_entry == NULL) { rs->sr_err = LDAP_NO_SUCH_OBJECT; rs->sr_text = "No such object found"; Debug(LDAP_DEBUG_ANY, "Custom overlay: noSuchObject error triggered\n"); } return rc; } and by using below command build .so file gcc -fPIC -shared \ -I "$OPENLDAP_SRC/include" \ -I "$OPENLDAP_SRC/servers/slapd" \ -I "$OPENLDAP_SRC/libraries/libldap" \ -I "$OPENLDAP_SRC/libraries/liblber" \ -o "my_overlay.c" "noSuchobject_overlay.so" \ -lldap we didnt get any error while building the .so file. but while loading the module by using below ldif file content getting error dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: /usr/lib/ldap/noSuchobject_overlay.so config="/etc/ldap/ldap.conf" root@lodsto-essvt:~# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f new_load_overlay.ldif modifying entry "cn=module{0},cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcModuleLoad> handler exited with 1 and we got stuck in this module load. May be can you review and propose proper steps and script to build the required module to get expected ldap behaviour. Thanks in advance. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[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 7901] slapschema reports error but returns 0
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=7901 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs_review -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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

[Issue 10324] New: Grammar error
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=10324 Issue ID: 10324 Summary: Grammar error Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ron(a)return.sh Target Milestone: --- In the documentation, y'all have: Acknowledgments The OpenLDAP Project is comprised of a team of volunteers. This document would not be possible without their contribution of time and energy. Either "comprises" or "composed of" should be used. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=6938 --- Comment #5 from Dhiraj Giria <dhiraj.giria(a)mitel.com> --- Thank you Matt, I have tried using mingw32 and mingw64 under MSYS2 environment. Using mingw32 and mingw64 fails during the configure step. Error while running mingw32: configure: error: IPv6 support requires getaddrinfo() and inet_ntop() Error with mingw64: Unable to load winsock.h and winsock2.h files as they collide with linux based socket libraries under sys folders. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=6938 --- Comment #4 from Matthew Hardin <mhardin(a)symas.com> --- Hello, Yes, I have confirmed that there are issues building OpenLDAP under MSYS2 with --enable-ipv6. What environment are you building under? Thanks, -Matt > On Apr 24, 2025, at 3:03 AM, openldap-its(a)openldap.org wrote: > > https://bugs.openldap.org/show_bug.cgi?id=6938 > > --- Comment #3 from Dhiraj Giria <dhiraj.giria(a)mitel.com> --- > Hi Matt > I have tried building OpenLDAP 2.6.9 version with flag enable-ipv6 flag for > Windows environment, but failed to do so successfully. Is it a valid ticket? > can you please confirm if we support openldap+ipv6 on Windows? > > Thanks > Dhiraj > > -- > You are receiving this mail because: > You are the assignee for the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 24 Apr '25

24 Apr '25

https://bugs.openldap.org/show_bug.cgi?id=6938 --- Comment #3 from Dhiraj Giria <dhiraj.giria(a)mitel.com> --- Hi Matt I have tried building OpenLDAP 2.6.9 version with flag enable-ipv6 flag for Windows environment, but failed to do so successfully. Is it a valid ticket? can you please confirm if we support openldap+ipv6 on Windows? Thanks Dhiraj -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

15 Apr '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 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs