- openldap-bugs - openldap.org

[Issue 7298] permissive modify control misparsed
by openldap-its＠openldap.org 30 Mar '24

30 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=7298 --- Comment #5 from lesignor(a)cirad.fr --- In the Microsoft documentation (https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/ld…), they write : ldctl_value No data for this control. In the berval structure, set bv_len to zero and bv_val to NULL. As they said set bv_len to zero, I guess some developer choose to send 04 00 to set the length to 0, and other consider to remove all fields. The ldap client, I use, is a dotnet client. I think it uses the c# sdk from Microsoft. Would it be possible to accept both implementation (null or empty) ? It will be a great help to migrate to openldap 2.6.x. Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10192] New: otp.c overlay - HOTP wrongly numbers gneration
by openldap-its＠openldap.org 28 Mar '24

28 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10192 Issue ID: 10192 Summary: otp.c overlay - HOTP wrongly numbers gneration Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: michal.pura(a)gmail.com Target Milestone: --- Hello, I am trying to use otp.c overlay but seems that numbers are not properly generated. In my case I have random secret like 'aaaabbbbccccdddd' and according to what Google Authenticator and https://www.verifyr.com/en/otp/check#hotp is generating we should have the following HOTP codes for above secret: 1 - 229789 2 - 801677 3 - 630108 4 - 214543 5 - 916392 6 - 346078 7 - 701644 8 - 865071 9 - 431248 10 - 355053 but, otp.c module is returning the following numbers: 1 - 441008 2 - 465617 3 - 669281 4 - 042697 5 - 461210 6 - 620979 7 - 700859 8 - 573924 9 - 805067 10 - 135880 The secret is properly generated and used in the code. I've checked it under debugger. The hash algorithm is defined as 1.2.840.113549.2.7 -> HMAC-WITH-SHA1. What is wrong? -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=7400 --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • ae1c8f18 by Howard Chu at 2024-02-20T15:55:37+00:00 ITS#7400 slapo-memberof: delete note about deprecation -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=7400 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • f30def77 by Howard Chu at 2024-03-26T16:38:10+00:00 ITS#7400 slapo-memberof: delete note about deprecation -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10082] New: More dynlist eval tweaks
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10082 Issue ID: 10082 Summary: More dynlist eval tweaks Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When the memberOf attribute is a user attribute instead of operational, it will be expanded on any search for (all user attributes). If the search is filtering on objectclasses that don't contain this attribute, that's wasted work. Check for a matching objectclass in the filter before doing that. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

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

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Assignee|bugs(a)openldap.org |hyc(a)openldap.org --- Comment #38 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE0.9: • 83dc42c5 by Howard Chu at 2024-03-26T14:52:42+00:00 ITS#9037 mdb_page_search: fix error code when DBI record is missing -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10189] New: Extra `#endif` in `libraries/liblunicode/utbm/utbm.h`
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10189 Issue ID: 10189 Summary: Extra `#endif` in `libraries/liblunicode/utbm/utbm.h` Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: annieliu(a)roblox.com Target Milestone: --- In `libraries/liblunicode/utbm/utbm.h` (https://github.com/openldap/openldap/blob/master/libraries/liblunicode/utbm…), only one `#ifndef` macro is defined, but there are two `#endif`s. Wondering if this is a typo? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10190] New: Stack space exhaustion on windows due to FD_SETSIZE
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10190 Issue ID: 10190 Summary: Stack space exhaustion on windows due to FD_SETSIZE Product: OpenLDAP Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: varunpatil(a)ucla.edu Target Milestone: --- Setting FD_SETSIZE is only effective on Windows and BSD, and is currently set to an unreasonable default of 4096. Each fd_set is initialized with an array of file descriptors of this size; this allocates 8*4096 bytes on 64-bit machines, which quickly exhausts the small stack space on Windows. This patch sets the default to a more reasonable value of 128; the default value on Windows currently is 64. -- You are receiving this mail because: You are on the CC list for the issue.

2 8

[Issue 9378] New: Crash in mdb_put() / mdb_page_dirty()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9378 Issue ID: 9378 Summary: Crash in mdb_put() / mdb_page_dirty() Product: LMDB Version: 0.9.26 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: nate(a)kde.org Target Milestone: --- The KDE Baloo file indexer uses lmdb as its database (source code available at https://invent.kde.org/frameworks/baloo). Our most common crash, with over 100 duplicate bug reports, is in lmdb. Here's the bug report tracking it: https://bugs.kde.org/show_bug.cgi?id=389848. The version of lmdb does not seem to matter much. We have bug reports from Arch users with lmdb 0.9.26 as well as bug reports from people using many earlier versions. Here's an example backtrace, taken from https://bugs.kde.org/show_bug.cgi?id=426195: #6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #7 0x00007f3c0bbb9859 in __GI_abort () at abort.c:79 #8 0x00007f3c0b23ba83 in mdb_assert_fail (env=0x55e2ad710600, expr_txt=expr_txt@entry=0x7f3c0b23e02f "rc == 0", func=func@entry=0x7f3c0b23e978 <__func__.7221> "mdb_page_dirty", line=line@entry=2127, file=0x7f3c0b23e010 "mdb.c") at mdb.c:1542 #9 0x00007f3c0b2306d5 in mdb_page_dirty (mp=<optimized out>, txn=0x55e2ad7109f0) at mdb.c:2114 #10 mdb_page_dirty (txn=0x55e2ad7109f0, mp=<optimized out>) at mdb.c:2114 #11 0x00007f3c0b231966 in mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7f3c0727aee8, mc=<optimized out>) at mdb.c:2308 #12 0x00007f3c0b231ba3 in mdb_page_touch (mc=mc@entry=0x7f3c0727b420) at mdb.c:2495 #13 0x00007f3c0b2337c7 in mdb_cursor_touch (mc=mc@entry=0x7f3c0727b420) at mdb.c:6523 #14 0x00007f3c0b2368f9 in mdb_cursor_put (mc=mc@entry=0x7f3c0727b420, key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820, flags=flags@entry=0) at mdb.c:6657 #15 0x00007f3c0b23976b in mdb_put (txn=0x55e2ad7109f0, dbi=5, key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820, flags=flags@entry=0) at mdb.c:9022 #16 0x00007f3c0c7124c5 in Baloo::DocumentDB::put (this=this@entry=0x7f3c0727b960, docId=<optimized out>, docId@entry=27041423333263366, list=...) at ./src/engine/documentdb.cpp:79 #17 0x00007f3c0c743da7 in Baloo::WriteTransaction::replaceDocument (this=0x55e2ad7ea340, doc=..., operations=operations@entry=...) at ./src/engine/writetransaction.cpp:232 #18 0x00007f3c0c736b16 in Baloo::Transaction::replaceDocument (this=this@entry=0x7f3c0727bc10, doc=..., operations=operations@entry=...) at ./src/engine/transaction.cpp:295 #19 0x000055e2ac5d6cbc in Baloo::UnindexedFileIndexer::run (this=0x55e2ad79ca20) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60 #20 0x00007f3c0c177f82 in QThreadPoolThread::run (this=0x55e2ad717f20) at thread/qthreadpool.cpp:99 #21 0x00007f3c0c1749d2 in QThreadPrivate::start (arg=0x55e2ad717f20) at thread/qthread_unix.cpp:361 #22 0x00007f3c0b29d609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #23 0x00007f3c0bcb6103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 -- You are receiving this mail because: You are on the CC list for the issue.

1 30

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #37 from Howard Chu <hyc(a)openldap.org> --- Fixed in git -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 26 Mar '24

26 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #36 from mdufour(a)audiokinetic.com --- This patch does fix the crash in my application repro case as well. We'll integrate it in our next minor release. Thanks much! -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 25 Mar '24

25 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #35 from Howard Chu <hyc(a)openldap.org> --- (In reply to mdufour from comment #34) > Thanks to the test application, I was able to identify a key missing step in > my description: process2 creates a named database (under a different name) > after dropping the initial one. I can reproduce the crash by inserting the > following lines @ 104: > > E(mdb_txn_begin(env, NULL, 0, &txn)); > E(mdb_dbi_open(txn, "id2", MDB_CREATE, &dbi)); > E(mdb_txn_commit(txn)); OK, that reproduces it. This patch should fix it, please test, thanks: diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 13d1aea39e..f0a65d97ab 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -6670,7 +6670,7 @@ mdb_page_search(MDB_cursor *mc, MDB_val *key, int flags) MDB_node *leaf = mdb_node_search(&mc2, &mc->mc_dbx->md_name, &exact); if (!exact) - return MDB_NOTFOUND; + return MDB_BAD_DBI; if ((leaf->mn_flags & (F_DUPDATA|F_SUBDATA)) != F_SUBDATA) return MDB_INCOMPATIBLE; /* not a named DB */ rc = mdb_node_read(&mc2, leaf, &data); -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 24 Mar '24

24 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #34 from mdufour(a)audiokinetic.com --- Thanks to the test application, I was able to identify a key missing step in my description: process2 creates a named database (under a different name) after dropping the initial one. I can reproduce the crash by inserting the following lines @ 104: E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, "id2", MDB_CREATE, &dbi)); E(mdb_txn_commit(txn)); -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 22 Mar '24

22 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #33 from Howard Chu <hyc(a)openldap.org> --- (In reply to mdufour from comment #31) > I am able to reproduce the crash in a scenario with two processes accessing > the same LMDB file, where: > > - process1 opens a named database. > - process2 drops this named database. > - process1 writes to the initial named database (using the dbi it was > holding on to) -> this is where we crash. > > It seems that mdb_page_search returns MDB_NOTFOUND because the named > database is gone, leaving mc->mc_pg[0] NULL. Thanks for that info. Unfortunately I still can't reproduce that crash. I've attached the test code I wrote based on your info. It forks off a child to do the process2 actions. You must press RETURN when you're ready for process 1 to proceed. I just get more MDB_NOTFOUND results when process1 tries to write again. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 22 Mar '24

22 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #32 from Howard Chu <hyc(a)openldap.org> --- Created attachment 1015 --> https://bugs.openldap.org/attachment.cgi?id=1015&action=edit Attempted reproduction -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9193] New: HTML in mailing list description
by openldap-its＠openldap.org 19 Mar '24

19 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9193 Bug ID: 9193 Summary: HTML in mailing list description Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/ contains code for links and formatting, but all inside of a <pre> block. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 18 Mar '24

18 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #31 from mdufour(a)audiokinetic.com --- I am able to reproduce the crash in a scenario with two processes accessing the same LMDB file, where: - process1 opens a named database. - process2 drops this named database. - process1 writes to the initial named database (using the dbi it was holding on to) -> this is where we crash. It seems that mdb_page_search returns MDB_NOTFOUND because the named database is gone, leaving mc->mc_pg[0] NULL. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 16 Mar '24

16 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #30 from mdufour(a)audiokinetic.com --- We're on revision ce200dca of the main openldap repo from Aug 27, 2023. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #29 from Howard Chu <hyc(a)openldap.org> --- (In reply to mdufour from comment #28) > Apologies, in the last message, the provide line of code is indeed 7998, the > crash location (and not 8183 as written). It is slightly different from the > official mdb.c due to some unrelated local changes earlier in the file. You didn't specify which version of LMDB you're using. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #28 from mdufour(a)audiokinetic.com --- Apologies, in the last message, the provide line of code is indeed 7998, the crash location (and not 8183 as written). It is slightly different from the official mdb.c due to some unrelated local changes earlier in the file. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9037] observing crash in mdb_cursor_put()
by openldap-its＠openldap.org 15 Mar '24

15 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9037 --- Comment #27 from mdufour(a)audiokinetic.com --- We are also seeing rare instances of this crash since we released a version of our product which uses LMDB. Specifically, call stack is: mdb_cursor_put(MDB_cursor * mc, MDB_val * key, MDB_val * data, unsigned int flags) Line 7998 mdb_put(MDB_txn * txn, unsigned int dbi, MDB_val * key, MDB_val * data, unsigned int flags) Line 10107 where line 8183 is nsize = IS_LEAF2(mc->mc_pg[mc->mc_top]) ? key->mv_size : mdb_leaf_size(env, key, rdata); and mc->mc_top == 0 mc->mc_pg[0] == NULL rc == -30798 Although we do not have a reproduction case, we do have a full crash dump with heap of an unoptimized debug build of our application. There is no evidence of stack corruption (in fact, mc->mc_pg[1] is still 0xcccccccccccccccc as per the msvc run-time check initialization). Unfortunately we do not have the matching LMDB file. Anything we can provide to help narrow down the issue? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10187] New: I need to build an LDAP server from this image that runs as non-root
by openldap-its＠openldap.org 12 Mar '24

12 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10187 Issue ID: 10187 Summary: I need to build an LDAP server from this image that runs as non-root Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: deepakganiger4(a)gmail.com Target Milestone: --- I need to build an LDAP server from this image that runs as non-root. Is there a way to do this? I've tried creating a user with root privileges and then running as this user, but the server fails to start. Our Kubernetes environment requires that we run all pods as non-root -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10184] New: slapo-translucent
by openldap-its＠openldap.org 05 Mar '24

05 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=10184 Issue ID: 10184 Summary: slapo-translucent Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: marco.esposito(a)gmail.com Target Milestone: --- I am currently experiencing an issue with an OpenLDAP instance configured with the slapo-translucent overlay. After performing an ldapmodify: # ldapmodify -x -D cn=Manager,dc=example,dc=com -W -H ldap:/// <<EOF dn: uid=user,ou=People,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 99 EOF LDAP queries requesting only translucent local attributes do not return results unless both the remote and local attributes are included in the filter. Here is an example illustrating the behavior: Query with both remote and local attributes in the filter after ldapmodify (works correctly): # ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b "ou=People,dc=example,dc=com" "(uid=user)" uid uidNumber # extended LDIF # # LDAPv3 # base <ou=People,dc=example,dc=com> with scope subtree # filter: uid=user # requesting: uid uidNumber # # user, People, example.com dn: uid=user,ou=People,dc=example,dc=com uidNumber: 99 uid: user # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Query with only local attributes in the filter after ldapmodify (does not return results): # ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b "ou=People,dc=example,dc=com" "(uid=user)" uidNumber # extended LDIF # # LDAPv3 # base <ou=People,dc=example,dc=com> with scope subtree # filter: uid=user # requesting: uidNumber # # search result search: 2 result: 0 Success # numResponses: 1 While attempting to debug the issue, I believe the problem may be related to the code in lines 928 - 940 of the file overlays/translucent.c: https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/over… Specifically, I suspect that the issue may be related to the conditions within the 'if' statement. I have carefully reviewed the slapd instance configuration and overlay settings, but I have not been able to identify the root cause. Any assistance or advice on resolving this issue would be greatly appreciated. Thank you for your time and support. Best regards, Marco -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10181] New: No support for setting allowed signature algorithms or groups/curves for OpenSSL TLS handshake
by openldap-its＠openldap.org 22 Feb '24

22 Feb '24

https://bugs.openldap.org/show_bug.cgi?id=10181 Issue ID: 10181 Summary: No support for setting allowed signature algorithms or groups/curves for OpenSSL TLS handshake Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: stephen.wall(a)redcom.com Target Milestone: --- The list of LDAP_OPT_X_TLS_* constants does not include anything for setting allowed curves/groups (SSL_CTX_set1_groups_list()) or signature algorithms (SSL_CTX_set1_client_sigalgs_list(), SSL_CTX_set1_sigalgs_list()) for TLS handshakes. Support for OpenSSL's SSL_CONF_cmd() et al. API would also be a nice addition. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs