- openldap-bugs - openldap.org

[Issue 10208] New: build test failure: test076-authid-rewrite (2.6.8 (RE26)
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10208 Issue ID: 10208 Summary: build test failure: test076-authid-rewrite (2.6.8 (RE26) Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Testing RE26 on Gentoo Linux. Test 076 fails with "generic failure: internal error: failed to init cipher 'rc4'" >>>>> 00:07:19 Starting test076-authid-rewrite for mdb... running defines.sh Starting slapd on TCP/IP port 9011... /home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests Using ldapsearch to check that slapd is running... Checking whether DIGEST-MD5 is supported... Adding schema and database... Using ldapadd to populate the database... Adding olcAuthzRegexp rule for static mapping... Testing ldapwhoami as Manager... ldap_sasl_interactive_bind: Local error (-2) additional info: SASL(-1): generic failure: internal error: failed to init cipher 'rc4' ldapwhoami failed (254)! >>>>> 00:07:20 Failed test076-authid-rewrite for mdb after 1 seconds (exit 254) make[2]: *** [Makefile:320: mdb-yes] Error 254 make[2]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests' make[1]: *** [Makefile:287: test] Error 2 make[1]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests' make: *** [Makefile:298: test] Error 2 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10209] New: OpenBSD Build failure (2.6.8 (RE26)
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10209 Issue ID: 10209 Summary: OpenBSD Build failure (2.6.8 (RE26) Product: OpenLDAP Version: unspecified Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brett(a)gladserv.com Target Milestone: --- Build failure on OpenBSD 7.2. NB: OpenBSD uses LibreSSL, not OpenSSL, and I have no idea if that's supported, but configure should at least pick that up I think. libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_o.c -fPIC -DPIC -o .libs/tls_o.o tls_o.c:228:19: error: use of undeclared identifier 'OPENSSL_INIT_NO_ATEXIT' OPENSSL_init_ssl(OPENSSL_INIT_NO_ATEXIT, NULL); ^ 1 error generated. *** Error 1 in libraries/libldap (Makefile:432 'tls_o.lo') *** Error 2 in libraries (Makefile:317 'all-common': @for i in liblutil liblber liblunicode libldap librewrite ; do echo " Entering ...) *** Error 2 in /home/bacs/openldap-OPENLDAP_REL_ENG_2_6 (Makefile:325 'all-common': @for i in include libraries clients servers tests doc ; ...) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10166] New: 2.6.7: not redy for gcc 14.x
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10166 Issue ID: 10166 Summary: 2.6.7: not redy for gcc 14.x 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: kloczko.tomasz(a)gmail.com Target Milestone: --- Looks like last version build fails with latest gcc 14.x which is now used in fedora rawhide. cd slapi && make -k all make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/openldap-2.6.7/servers/slapd/slapi' /bin/sh ../../../libtool --mode=compile /usr/bin/gcc -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -DLDAP_CONNECTIONLESS -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c libtool: compile: /usr/bin/gcc -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -DLDAP_CONNECTIONLESS -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c -fPIC -DPIC -o .libs/plugin.o plugin.c: In function 'slapi_int_read_config': plugin.c:697:69: error: passing argument 3 of 'plugin_pblock_new' from incompatible pointer type [-Wincompatible-pointer-types] 697 | pPlugin = plugin_pblock_new( iType, numPluginArgc, c->argv ); | ~^~~~~~ | | | char ** plugin.c:71:21: note: expected 'ConfigArgs *' {aka 'struct config_args_s *'} but argument is of type 'char **' 71 | ConfigArgs *c ) | ~~~~~~~~~~~~^ make[3]: *** [Makefile:387: plugin.lo] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10214] New: Reduce library dependencies
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10214 Issue ID: 10214 Summary: Reduce library dependencies Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- Currently, slapd links libsystemd to notify service state to systemd. However, libsystemd link several unnecessary libraries, which increases security risks. The systemd documentation provides a method to send state notifications to systemd using a simple protocol without the need to link against libsystemd. https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html I propose removing libsystemd and its depended libraries, similar to the approach taken by OpenSSH. Applying this fix reduced the following ten dependencies in the RHEL 8 environment. - libsystemd.so.0 - libblkid.so.1 - libcap.so.2 - libgcc_s.so.1 - libgcrypt.so.20 - libgpg-error.so.0 - liblz4.so.1 - liblzma.so.5 - libmount.so.1 - librt.so.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10179] New: back-asyncmeta(5) man page incorrectly mentions "rewrite"
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10179 Issue ID: 10179 Summary: back-asyncmeta(5) man page incorrectly mentions "rewrite" Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Man page for back-asyncmeta mentions the rewrite options, yet asyncmeta does not support the rewrite engine at the moment. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10164] New: back-meta hangs when used with dynlist overlay
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10164 Issue ID: 10164 Summary: back-meta hangs when used with dynlist overlay 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: nivanova(a)symas.com Target Milestone: --- When back-meta is configured with the dynlist overlay, on a search request that triggers dynlist, it will hang. This happens because of a bug in back-meta that is only revealed when an overlay issues an internal operation while processing a result or an entry, as dynlist does, as apposed to issuing it when the client op is first received ( on the way "down" to the backend). The issue is reproduced by configuring dynlist over a back-meta database, and sending a subtree search request with the database suffix as dn. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10216] New: Channel binding enforced on AD with AD cert using EDCSA-SHA384 fails
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10216 Issue ID: 10216 Summary: Channel binding enforced on AD with AD cert using EDCSA-SHA384 fails Product: OpenLDAP Version: 2.6.7 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: --- Secure LDAP connections to the target Windows server 2019 DC began failing after the Windows Server DC certificate was updated to an Elliptic Curve Public Key (384 bits) with the sha384ECDSA signature algorithm and sha384 signature hash algorithm specified. The connections were previously successful when the Windows server DC certificate specified an RSA Public Key certificate with signature algorithm sha256RSA and signature hash algorithm sha256 specified. Once the Windows server domain controller certificate is upgraded to the ECC public key, subsequent secure ldap connection attempts fail. If channel binding is turned off on the Windows AD target server, secure ldap connections will succeed using starttls. If Windows server domain controller certificate is upgraded to ECC public key and ldap channel binding is enforced, subsequent secure ldap connection attempts fail with this error message: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C09070F, comment: AcceptSecurityContext error, data 80090346, v4563 Expected results: Kerberos SASL should work with STARTTLS even when AD certificate is ECC and SASL_CBINDING is set to "tls-endpoint" Actual results: Kerberos SASL only works with STARTTLS even when AD certificate is RSA and SASL_CBINDING is set to "tls-endpoint"; it fails when AD certificate is ECC Additional information: According to the OpenSSL maintainer, there might be a bug in the OpenLDAP code: it uses EVP_get_digestbynid() to find a digest algorithm based on the signature algorithm, but there might be no such mapping in EC compared to the RSA case. OpenLDAP needs to use OBJ_find_sigid_algs() to find the right algorithm. Possibly, this is the failing code: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… Instead of X509_get_signature_nid() OpenLDAP code probably should call something like OBJ_find_sigid_algs(X509_get_signature_nid(cert), &md_nid, &pk_nid). The former only supports mapping for a few known signature algorithms, but everything did work, most likely due to a fallback to sha256 in case the digest wasn't really found. Judging by https://github.com/openssl/openssl/issues/14278 and https://github.com/openssl/openssl/issues/14467, a better API is coming but not currently available (and as it was in the state for a few years, it probably won't be coming soon) -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10212] New: read-only tools may use wrong meta page
by openldap-its＠openldap.org 14 May '24

14 May '24

https://bugs.openldap.org/show_bug.cgi?id=10212 Issue ID: 10212 Summary: read-only tools may use wrong meta page Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- On a quiescent database that's only used for read-only txns, the txnid won't be initialized so it remains set to zero. Then only meta page zero will get used, even if page one is newer. Thus all information retrieved will be stale by one txn. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9921] New: Tautology in clients/tools/common.c:print_vlv()
by openldap-its＠openldap.org 08 May '24

08 May '24

https://bugs.openldap.org/show_bug.cgi?id=9921 Issue ID: 9921 Summary: Tautology in clients/tools/common.c:print_vlv() Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… contains: tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE, ldif ? "vlvResult" : "vlvResult", buf, rc ); The second parameter is always vlvResult, irrespective of the value of ldif. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10215] New: [QUESTION] FIPS Validated password hashing
by openldap-its＠openldap.org 07 May '24

07 May '24

https://bugs.openldap.org/show_bug.cgi?id=10215 Issue ID: 10215 Summary: [QUESTION] FIPS Validated password hashing Product: OpenLDAP Version: 2.4.54 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 11tete11(a)gmail.com Target Milestone: --- Hi! we are in process of a certification, and we are using openldap of ubuntu pro fips 20.04, that its the 2.4.54 At some point the auditor ask us, how the passwords are stored into ldap, and we found this: https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass… seems that that module do not use a FIPS validated library like "openssl" that comes with ubuntu fips. and make it's own implementation of the sha512. Is there any ldap module that uses the openssl library of the SO that in this case its the openssl 1.1.1f to hash its passwords?, could be this https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass… maybe if i'm understanding right? thx! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10198] New: Crash in mdb_strerr on Windows
by openldap-its＠openldap.org 07 May '24

07 May '24

https://bugs.openldap.org/show_bug.cgi?id=10198 Issue ID: 10198 Summary: Crash in mdb_strerr on Windows Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: b.koch(a)beckhoff.com Target Milestone: --- The call to FormatMessageA in mdb_strerr crashes on Windows 10 for error code 112 (disk full). Its "Arguments" parameter is an invalid pointer. The documentation says that the parameter should be ignored because of FORMAT_MESSAGE_IGNORE_INSERTS but my copy of Windows disagrees. Documentation for FormatMessageA: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-form… The error is (with addresses replaced by <...>): Exception thrown at <RtlFormatMessageEx> (ntdll.dll) in ConsoleApplication1.exe: 0xC0000005: Access violation reading location <buf+8*1024>. Trivial fix: Change the last parameter to NULL (in this call: https://github.com/LMDB/lmdb/blob/8645e92b937794c06f0c66dfae64e425a085b6cd/…) Bug 8361 is raising some additional issues in this code and it implies that the va_list is somehow related to the padding hack (but I don't understand how that is, to be honest), so I'm not sure whether the trivial fix would be fine. Here is some code to reproduce the crash outside of liblmdb (tested with Visual Studio 2022, x86 and x64, C++ console project): #include <iostream> #include <windows.h> int main() { std::cout << "Hello World!\n"; char buf[1024]; FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, 112, 0, buf, sizeof(buf), (va_list*)buf + 1024); char* msg = buf; std::cout << msg; } -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10210] New: ldapurl manpage references options that no longer exist
by openldap-its＠openldap.org 30 Apr '24

30 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10210 Issue ID: 10210 Summary: ldapurl manpage references options that no longer exist Product: OpenLDAP Version: 2.6.7 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: --- -h ldaphost Set the host. -p ldapport Set the TCP port. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10195] New: permissive modify control without value
by openldap-its＠openldap.org 30 Apr '24

30 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10195 Issue ID: 10195 Summary: permissive modify control without value 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: lesignor(a)cirad.fr Target Milestone: --- Hello, A windows ldap client (dotnet) format the request with oid permissive modify control like this : 00d0 30 84 00 00 00 1e 04 17 ........0....... 00e0 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 2e 31 1.2.840.113556.1 00f0 2e 34 2e 31 34 31 33 01 01 ff 04 00 .4.1413..... The last 2 bytes 04 00 seems to indicate no value (length of value = 0 ?). With openldap 2.4.x this request was accepted. With openldap 2.5.x or openldap 2.6.x, this request is rejected for invalid protocol with error message : permissiveModify control value not absent With ldapmodify from openldap, the same request is formatted without the last 2 bytes and is accepted. Could it be possible to accept request with control without value formatted with 04 00 to indicate no value ? It will help to migrate from openldap 2.4.x to 2.5.x or 2.6.x Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10203] New: no pkgconfig file included for liblmdb
by openldap-its＠openldap.org 30 Apr '24

30 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10203 Issue ID: 10203 Summary: no pkgconfig file included for liblmdb Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: otto(a)drijf.net Target Milestone: --- liblmdb does not ship with a pkgconfig file. More and more build systems rely on presense of a pkgconfig file, so it would be nice if liblmdb installed oneone. An example: prefix=/usr/local exec_prefix=${prefix} libdir=${prefix}/lib includedir=${prefix}/include Name: lmdb Description: Lightning memory-mapped database: key-value data store URL: https://www.symas.com/symas-embedded-database-lmdb Version: 0.9.32 Libs: -L${libdir} -llmdb Cflags: -I${includedir} Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 8613] slapo-memberOf documentation update (Unsafe to use with replication)
by openldap-its＠openldap.org 28 Apr '24

28 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=8613 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10167 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

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

1 0

[Issue 10202] New: slapd fails to start if compiled with --enable-overlays=yes
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10202 Issue ID: 10202 Summary: slapd fails to start if compiled with --enable-overlays=yes 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: nivanova(a)symas.com Target Milestone: --- Statically compiling all overlays produces the following error at slapd startup: 66192034.2adbbeb4 0x73de9d4547c0 register_at: AttributeType "( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' EQUALITY distinguishedNameMatch USAGE dSAOperation NO-USER-MODIFICATION X-ORIGIN 'iPlanet Delegated Administrator' )": Duplicate attributeType, 1.2.840.113556.1.2.102 66192034.2adc2a97 0x73de9d4547c0 overlay_register("nestgroup"): name already in use. 66192034.2adc44ed 0x73de9d4547c0 nestgroup overlay setup failed, err -1 66192034.2adc5016 0x73de9d4547c0 slapd: overlay_init failed 66192034.2adc5e14 0x73de9d4547c0 slapd destroy: freeing system resources. 66192034.2adefbff 0x73de9d4547c0 slapd stopped. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

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

08 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 10201] New: Update autotools to 2.71
by openldap-its＠openldap.org 07 Apr '24

07 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10201 Issue ID: 10201 Summary: Update autotools to 2.71 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: quanah(a)openldap.org Target Milestone: --- Update to newer autotools to work with current configure.ac requirements -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10199] New: pwdPolicySubentry set at user level
by openldap-its＠openldap.org 05 Apr '24

05 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10199 Issue ID: 10199 Summary: pwdPolicySubentry set at user level Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: kiruthiga_rajangam(a)comcast.com Target Milestone: --- I have three distinct password policies, and I aim to apply one of them to a user group so that members of the group inherit the policy. However, when I set the pwdPolicySubentry attribute of the group, the members do not seem to inherit the policy automatically. Instead, each member must be individually assigned the pwdPolicySubentry attribute for the policy to take effect. Is there something I'm overlooking in this process? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10200] New: Can pcacheTemplate support '!' operator
by openldap-its＠openldap.org 04 Apr '24

04 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10200 Issue ID: 10200 Summary: Can pcacheTemplate support '!' operator Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: shaosong.li(a)salesforce.com Target Milestone: --- Hi, I am using Openldap V2.5.17 and pcache engine for cache. After multiple rounds of testing, I found the '!" is not supported in the pcacheTemplate, such as below, which is used for filter from ldap query (!(uidNumber=0)). pcacheTemplate (!(uidNumber=)) 0 6000 300 0 0 While checking the source code, i don't see the '!' operator supported, however, I do see '&' and '|' in the source code. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv… Thanks, -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10196] New: ldapsearch with -h localhost resulting dns lookup
by openldap-its＠openldap.org 03 Apr '24

03 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10196 Issue ID: 10196 Summary: ldapsearch with -h localhost resulting dns lookup Product: OpenLDAP Version: 2.4.46 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: mca100309(a)gmail.com Target Milestone: --- ldapsearch -h localhost -p 16611 xxxxxxxx socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3 setsockopt(3, SOL_IPV6, IPV6_RECVERR, [1], 4) = 0 connect(3, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fd03::a", &sin6_addr), sin6_scope_id=0}, 28) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "R$\1\0\0\1\0\0\0\0\0\0'odinfn5gceir201-eir"..., 57, MSG_NOSIGNAL, NULL, 0) = 57 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [57]) = 0 recvfrom(3, "R$\201\202\0\1\0\0\0\0\0\0'odinfn5gceir201-eir"..., 1024, 0, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fd03::a", &sin6_addr), sin6_scope_id=0}, [28]) = 57 close(3) Whenever ldapsearch is executed localhost it it initiating a dnslookup also. It is happening in some platform only -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[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 02 Apr '24

02 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=7298 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10195 -- 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 31 Mar '24

31 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs