openldap-bugs March 2024

openldap-bugs@openldap.org

2 participants
69 discussions

[Issue 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

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 3

[Issue 10162] New: Fix for binary attributes data corruption in back-sql
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10162 Issue ID: 10162 Summary: Fix for binary attributes data corruption in back-sql Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dex.tracers(a)gmail.com Target Milestone: --- Created attachment 1006 --> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit Fix for binary attributes corruption on backed-sql I've configured slapd to use back-sql (mariadb through odbc) and observed issues with the BINARY data retrievals from the database. The length of the attributes was properly reported, but the correct data inside was always 16384 bytes and after that point - some junk (usually filled-up with AAAAAAAA and some other attributes data from memory). During the debugging - I've noticed that: - The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for BINARY columns when SQLBindCol is done inside of the "backsql_BindRowAsStrings_x" function - After SQLFetch is done - data in row->cols[i] is fetched up to the specified MAX_ATTR_LEN - After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is represented inside of the row->value_len I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills it with the specified amount of data (MAX_ATTR_LEN), but when forming the actual attribute data - uses the length from row->value_len and so everything from 16384 bytes position till row->value_len is just a junk from the memory (uninitialized, leftovers, data from other variables). After an investigation, I've find-out that: - for BINARY or variable length fields - SQLGetData should be used - SQLGetData supports chunked mode (if length is unknown) or full-read mode if the length is known - it could be used in pair with SQLBindCol after SQLFetch (!) Since we have the correct data length inside of row->value_len, I've just added the code to the backsql_get_attr_vals() function to overwrite the corrupted data with the correct data by issuing SQLGetData request. And it worked - binary data was properly retrieved and reported over LDAP! My current concerns / help needed - I'm not very familiar with the memory allocation/deallocation mechanisms, so I'm afraid that mentioned change can lead to memory corruption (so far not observed). Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and applied on the master branch for easier review/application). -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10180] New: mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty()
by openldap-its＠openldap.org 07 Apr '24

07 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10180 Issue ID: 10180 Summary: mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty() Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: dominik(a)greysector.net Target Milestone: --- I'm experiencing a SIGABRT-induced crash in nheko, which uses lmdb for its database (~/.local/share/nheko/nheko/#hash#/{data,lock}.mdb). The assertion triggering the SIGABRT seems to be happening here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblmdb/… The crash happens on every nheko startup since yesterday, so I assume something added to the database is triggering it. Full backtrace from gdb: ... (gdb) run Starting program: /usr/bin/nheko [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff04006c0 (LWP 8281)] [New Thread 0x7fffefa006c0 (LWP 8282)] [New Thread 0x7fffee2006c0 (LWP 8283)] [New Thread 0x7fffed8006c0 (LWP 8284)] [New Thread 0x7fffece006c0 (LWP 8285)] [New Thread 0x7fffe7e006c0 (LWP 8286)] [Thread 0x7fffe7e006c0 (LWP 8286) exited] [New Thread 0x7fffe7e006c0 (LWP 8287)] [New Thread 0x7fffe74006c0 (LWP 8288)] [Thread 0x7fffe7e006c0 (LWP 8287) exited] [Thread 0x7fffe74006c0 (LWP 8288) exited] [New Thread 0x7fffe74006c0 (LWP 8289)] [New Thread 0x7fffe7e006c0 (LWP 8290)] [Thread 0x7fffe74006c0 (LWP 8289) exited] [Thread 0x7fffe7e006c0 (LWP 8290) exited] [New Thread 0x7fffe7e006c0 (LWP 8292)] [New Thread 0x7fffe74006c0 (LWP 8293)] [New Thread 0x7fffe6a006c0 (LWP 8294)] [New Thread 0x7fffe60006c0 (LWP 8295)] [New Thread 0x7fffe56006c0 (LWP 8296)] [New Thread 0x7fffe4c006c0 (LWP 8297)] [New Thread 0x7fffdfe006c0 (LWP 8298)] [New Thread 0x7fffdf4006c0 (LWP 8299)] [New Thread 0x7fffd7e006c0 (LWP 8300)] [New Thread 0x7fffd74006c0 (LWP 8301)] [New Thread 0x7fffd6a006c0 (LWP 8302)] [New Thread 0x7fffd60006c0 (LWP 8303)] [Thread 0x7fffd60006c0 (LWP 8303) exited] [Thread 0x7fffd6a006c0 (LWP 8302) exited] [New Thread 0x7fffd6a006c0 (LWP 8304)] [2024-02-16 11:52:33.040] [ui] [info] Restoring window size 1424x885 [2024-02-16 11:52:33.051] [ui] [info] WebRTC: initialised GStreamer 1.22.9 [New Thread 0x7fffd60006c0 (LWP 8305)] [New Thread 0x7fffd52006c0 (LWP 8306)] [New Thread 0x7fffcfe006c0 (LWP 8307)] [New Thread 0x7fffcf4006c0 (LWP 8308)] [New Thread 0x7fffcea006c0 (LWP 8309)] [Thread 0x7fffcea006c0 (LWP 8309) exited] [New Thread 0x7fffcea006c0 (LWP 8310)] [Thread 0x7fffcea006c0 (LWP 8310) exited] [2024-02-16 11:52:33.342] [ui] [info] Loaded jdenticon plugin. [New Thread 0x7fffcea006c0 (LWP 8311)] [New Thread 0x7fffce0006c0 (LWP 8312)] [Thread 0x7fffce0006c0 (LWP 8312) exited] [Thread 0x7fffcea006c0 (LWP 8311) exited] [2024-02-16 11:52:33.557] [ui] [info] starting nheko 0.11.3 [New Thread 0x7fffcea006c0 (LWP 8313)] [2024-02-16 11:52:33.558] [ui] [info] User already signed in, showing chat page [2024-02-16 11:52:33.559] [ui] [info] Switching to chat page [New Thread 0x7fffce0006c0 (LWP 8314)] [2024-02-16 11:52:33.604] [qml] [warning] qrc:/qml/TopBar.qml:234:13: QML AbstractButton: Binding loop detected for property "implicitWidth" (qrc:/qml/TopBar.qml:234, ) [2024-02-16 11:52:33.604] [qml] [warning] qrc:/qml/TopBar.qml:241:30: QML EncryptionIndicator: Binding loop detected for property "sourceSize.height" (qrc:/qml/TopBar.qml:241, ) [2024-02-16 11:52:33.622] [ui] [info] Unity service available: true [New Thread 0x7fffcca006c0 (LWP 8315)] [New Thread 0x7fffbfe006c0 (LWP 8316)] [New Thread 0x7fffbf4006c0 (LWP 8317)] [2024-02-16 11:52:33.629] [qml] [warning] qrc:/qml/ChatPage.qml:105:17: QML RoomList: Binding loop detected for property "implicitWidth" (qrc:/qml/ChatPage.qml:105, ) [2024-02-16 11:52:33.629] [qml] [warning] qrc:/qml/ChatPage.qml:105:17: QML RoomList: Binding loop detected for property "implicitWidth" (qrc:/qml/ChatPage.qml:105, ) [New Thread 0x7fffbd2006c0 (LWP 8318)] [2024-02-16 11:52:33.719] [db] [info] database ready [2024-02-16 11:52:33.720] [db] [info] restoring state from cache [2024-02-16 11:52:33.729] [db] [info] Restored 150 rooms from cache [2024-02-16 11:52:33.770] [db] [info] Invalidating self verification status [New Thread 0x7fffb7e006c0 (LWP 8319)] [2024-02-16 11:52:33.775] [crypto] [info] ed25519 : <redacted> [2024-02-16 11:52:33.775] [crypto] [info] curve25519: <redacted> mdb.c:2185: Assertion 'rc == 0' failed in mdb_page_dirty() [New Thread 0x7fffb74006c0 (LWP 8320)] Thread 1 "nheko" received signal SIGABRT, Aborted. 0x00007ffff4eae834 in __pthread_kill_implementation () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff4eae834 in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x00007ffff4e5c8ee in raise () from /lib64/libc.so.6 #2 0x00007ffff4e448ff in abort () from /lib64/libc.so.6 #3 0x00007ffff780f56b in mdb_assert_fail.constprop.0 (env=0x5555572b3940, expr_txt=<optimized out>, func=<optimized out>, line=<optimized out>, file=0x7ffff781c9d0 "mdb.c") at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:1588 #4 0x00007ffff780da59 in mdb_page_dirty (txn=<optimized out>, mp=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2172 #5 mdb_page_dirty (txn=0x555557a50220, mp=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2172 #6 0x00007ffff781be5e in mdb_page_alloc.isra.0 (num=1, mp=0x7fffffffb768, mc=<optimized out>) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2366 #7 0x00007ffff7812e52 in mdb_page_touch (mc=mc@entry=0x7fffffffbcb0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:2486 #8 0x00007ffff7814ac7 in mdb_cursor_touch (mc=mc@entry=0x7fffffffbcb0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:6602 #9 0x00007ffff7817879 in _mdb_cursor_put (mc=mc@entry=0x7fffffffbcb0, key=key@entry=0x7fffffffc080, data=data@entry=0x7fffffffc090, flags=<optimized out>, flags@entry=0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:6736 #10 0x00007ffff78188ee in mdb_put (txn=0x555557a50220, dbi=17, key=0x7fffffffc080, data=0x7fffffffc090, flags=0) at /usr/src/debug/lmdb-0.9.32-1.fc39.x86_64/libraries/liblmdb/mdb.c:9150 #11 0x00005555559f41c2 in lmdb::dbi_put (flags=0, data=0x7fffffffc090, key=0x7fffffffc080, dbi=<optimized out>, txn=<optimized out>) at /usr/include/lmdb++.h:787 #12 lmdb::dbi::put(MDB_txn*, std::basic_string_view<char, std::char_traits<char> >, std::basic_string_view<char, std::char_traits<char> >, unsigned int) [clone .constprop.0] [clone .isra.0] (txn=<optimized out>, key=..., data=..., flags=0, this=<optimized out>) at /usr/include/lmdb++.h:1413 #13 0x00005555559521e5 in Cache::markUserKeysOutOfDate (this=this@entry=0x555557264f40, txn=..., db=..., user_ids=std::vector of length 1, capacity 1 = {...}, sync_token="s117629150_1_50402_53153589_3038507_9889_1030948_33315610_0_2131") at /usr/include/lmdb++.h:1187 #14 0x00005555559524d5 in Cache::markUserKeysOutOfDate (this=0x555557264f40, user_ids=std::vector of length 1, capacity 1 = {...}) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:4580 #15 0x00005555559333ee in operator() (__closure=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/encryption/SelfVerificationStatus.cpp:32 #16 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()> >::call (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146 #17 QtPrivate::Functor<SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256 #18 QtPrivate::QFunctorSlotObject<SelfVerificationStatus::SelfVerificationStatus(QObject*)::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=<optimized out>, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:443 #19 0x00007ffff58e9151 in QtPrivate::QSlotObjectBase::call (a=0x7fffffffc970, r=<optimized out>, this=0x5555567a6ff0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #20 doActivate<false> (sender=0x555556030bc0, signal_index=5, argv=0x7fffffffc970) at kernel/qobject.cpp:3925 #21 0x00007ffff58e4077 in QMetaObject::activate (sender=sender@entry=0x555556030bc0, m=<optimized out>, local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at kernel/qobject.cpp:3985 #22 0x0000555555977046 in ChatPage::contentLoaded (this=0x555556030bc0) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/redhat-linux-build/nheko_autogen/UVLADIE3JM/moc_ChatPage.cpp:820 #23 ChatPage::loadStateFromCache (this=0x555556030bc0) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/ChatPage.cpp:600 #24 0x0000555555977919 in ChatPage::bootstrap(QString, QString, QString)::{lambda()#1}::operator()() const [clone .lto_priv.0] () at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/ChatPage.cpp:497 #25 0x00007ffff58e9151 in QtPrivate::QSlotObjectBase::call (a=0x7fffffffcf00, r=<optimized out>, this=0x5555572b4c50) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #26 doActivate<false> (sender=0x555557264f40, signal_index=10, argv=0x7fffffffcf00) at kernel/qobject.cpp:3925 #27 0x00007ffff58e4077 in QMetaObject::activate (sender=sender@entry=0x555557264f40, m=<optimized out>, local_signal_index=local_signal_index@entry=7, argv=argv@entry=0x0) at kernel/qobject.cpp:3985 #28 0x000055555593873e in Cache::databaseReady (this=0x555557264f40) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/redhat-linux-build/nheko_autogen/UVLADIE3JM/moc_Cache_p.cpp:275 #29 Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool> > >, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>, bool) (this=0x555557264f40, toLoad=std::vector of length 0, capacity 0, callback=..., databaseReadyOnFinished=true) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:393 #30 0x000055555596e7f1 in operator() (__closure=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/Cache.cpp:457 #31 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()> >::call (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146 #32 QtPrivate::Functor<Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256 #33 QtPrivate::QFunctorSlotObject<Cache::loadSecretsFromStore(std::vector<std::pair<std::__cxx11::basic_string<char>, bool> >, std::function<void(const std::__cxx11::basic_string<char>&, bool, const std::__cxx11::basic_string<char>&)>, bool)::<lambda(QKeychain::Job*)> mutable::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=<optimized out>, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:443 #34 0x00007ffff58df9fb in QObject::event (this=0x555557264f40, e=0x7fffe8008f30) at kernel/qobject.cpp:1347 #35 0x00007ffff65aeb95 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x555557264f40, e=0x7fffe8008f30) at kernel/qapplication.cpp:3640 #36 0x00007ffff58b4e78 in QCoreApplication::notifyInternal2 (receiver=0x555557264f40, event=0x7fffe8008f30) at kernel/qcoreapplication.cpp:1064 #37 0x00007ffff58b5092 in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>) at kernel/qcoreapplication.cpp:1462 #38 0x00007ffff58b8325 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x555555d6ef30) at kernel/qcoreapplication.cpp:1821 #39 0x00007ffff58b85dd in QCoreApplication::sendPostedEvents (receiver=<optimized out>, event_type=<optimized out>) at kernel/qcoreapplication.cpp:1680 #40 0x00007ffff59078cf in postEventSourceDispatch (s=0x555556019530) at kernel/qeventdispatcher_glib.cpp:277 #41 0x00007ffff5511e5c in g_main_dispatch (context=0x7fffe8000ec0) at ../glib/gmain.c:3476 #42 g_main_context_dispatch_unlocked (context=0x7fffe8000ec0) at ../glib/gmain.c:4284 #43 0x00007ffff556cf18 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x7fffe8000ec0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4349 #44 0x00007ffff550fad3 in g_main_context_iteration (context=0x7fffe8000ec0, may_block=1) at ../glib/gmain.c:4414 #45 0x00007ffff59073b9 in QEventDispatcherGlib::processEvents (this=0x555555f57ae0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #46 0x00007ffff58b383b in QEventLoop::exec (this=this@entry=0x7fffffffd640, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #47 0x00007ffff58bbacb in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #48 0x00007ffff5d60ead in QGuiApplication::exec () at kernel/qguiapplication.cpp:1863 #49 0x00007ffff65aeb09 in QApplication::exec () at kernel/qapplication.cpp:2832 #50 0x000055555570d10d in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/nheko-0.11.3-5.fc39.x86_64/src/main.cpp:405 (gdb) Looks like this was reported to nheko already, but they don't know what's causing it: https://github.com/Nheko-Reborn/nheko/issues/1303 . -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10194] New: Does LMDB support zero length keys?
by openldap-its＠openldap.org 02 Apr '24

02 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10194 Issue ID: 10194 Summary: Does LMDB support zero length keys? 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: roger.marsh(a)btinternet.com Target Milestone: --- I suspect the answer is 'No' but do not see a definitive statement. I followed the Python code and documentation trail below, but decided to ask here when I concluded I could not decide. Some Python code was adapted from berkeleydb to lmdb and gave an exception for a cursor.set_range_dup(b'', <some value>) call. Reading the lmdb/cffi.py code in site-packages prompted me to try cursor.set_range(b''), which seemed reasonable given that is what is done for berkeleydb, and it worked. However cursor.put(b'', <some value>) gave an exception quoting "mdb_put: MDB_BAD_VALSIZE ...". The documentation for the Python interface to LMDB at lmdb.readthedocs.io/ states behaviour for the empty bytestring for set_key(), set_key_dup(), and set_range(); but not for set_range_dup() or put(). Only set_key() and set_key_dup() describe empty bytestring as an error. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[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 #6 from Howard Chu <hyc(a)openldap.org> --- "No data for this control" means the data portion should not be sent at all. Setting bv_len and bv_val is just the quirk of how their API is designed. If we accept their published spec at face value, then their C# SDK implementation is wrong, because it is sending zero length data instead of "no data". You should submit a ticket to Microsoft to resolve this by either fixing their doc or fixing their SDK, whichever the case may be. The current OpenLDAP behavior conforms to their official spec so there is no OpenLDAP bug here. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2024