openldap-bugs February 2024

openldap-bugs@openldap.org

1 participants
114 discussions

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

22 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 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 10024] New: MDB_PREVSNAPSHOT broken
by openldap-its＠openldap.org 21 Feb '25

21 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10024 Issue ID: 10024 Summary: MDB_PREVSNAPSHOT broken Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: markus(a)objectbox.io Target Milestone: --- It seems that the patch #9496 had a negative side effect on MDB_PREVSNAPSHOT. In certain cases, when opening the DB using MDB_PREVSNAPSHOT, the previous (2nd latest) commit is not selected. Instead, reads show that the latest commit was selected voiding the effect of MDB_PREVSNAPSHOT. I observed this in our test cases a while back. Today, I was finally able to reproduce it and debug into it. When creating the transaction to read the data, I debugged into mdb_txn_renew0. Here, ti (MDB_txninfo; env->me_txns) was non-NULL. However, ti->mti_txnid was 0 (!) and thus txn->mt_txnid was set to 0. That's the reason for always selecting the first (index 0) meta page inside mdb_txn_renew0: meta = env->me_metas[txn->mt_txnid & 1]; This line occurs twice (once for read txn and once for write txn; it affects both txn types). Thus, the chances of MDB_PREVSNAPSHOT selecting the correct meta page is 50-50. It's only correct if the first meta page (index 0) is the older one. I believe that this is related to #9496 because the patch, that was provided there, removed the initialization of "env->me_txns->mti_txnid" in mdb_env_open2. This would explain why txn->mt_txnid inside mdb_txn_renew0 was set to 0. I can confirm that adding back the following two lines back in fixes MDB_PREVSNAPSHOT: if (env->me_txns) env->me_txns->mti_txnid = meta.mm_txnid; The said patch including the removal of these two lines was applied in the commit(s) "ITS#9496 fix mdb_env_open bug from #8704" (Howard Chu on 09.04.21). I hope this information is useful to find a suitable fix. Please let me know if you have questions. Also, I'd be happy to help confirming a potential fix with our test suite. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10056] New: test069-delta-multiprovider-starttls failures on static builds
by openldap-its＠openldap.org 08 Feb '25

08 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10056 Issue ID: 10056 Summary: test069-delta-multiprovider-starttls failures on static builds Product: OpenLDAP Version: 2.6.4 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: kaction(a)disroot.org Target Milestone: --- Hello. I am getting following test error when trying to build `openldap` statically: ``` [nix-shell:/tmp/openldap-static/openldap-2.6.4/tests]$ ./run test069-delta-multiprovider-starttls Cleaning up test run directory leftover from previous run. Running ./scripts/test069-delta-multiprovider-starttls for mdb... running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Waiting 5 seconds for slapd to start... Using ldapadd for context on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Waiting 5 seconds for slapd to start... Using ldapadd to populate server 1... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... Using ldapadd to populate server 2... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... Breaking replication between server 1 and 2... Using ldapmodify to force conflicts between server 1 and 2... Restoring replication between server 1 and 2... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... test failed - server 1 and server 2 databases differ (561) ``` I added line number (561) into error message to pinpoint it more precisely. And here is difference between databases: ``` --- /tmp/openldap-static/openldap-2.6.4/tests/testrun/server1.flt 2023-05-23 22:53:51.000965129 -0400 +++ /tmp/openldap-static/openldap-2.6.4/tests/testrun/server2.flt 2023-05-23 22:53:51.005965136 -0400 @@ -289,13 +289,10 @@ userPassword:: amFq dn: cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com -carLicense: 123-XYZ cn: James A Jones 2 cn: James Jones cn: Jim Jones -description: Amazing description: Bizarre -description: Mindboggling description: Stupendous employeeNumber: 64 employeeType: deadwood @@ -307,7 +304,7 @@ pager: +1 313 555 3923 postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com -sn: Surname +sn: Jones telephoneNumber: +1 313 555 0895 title: Mad Cow Researcher, UM Alumni Association uid: jaj ``` Suggestions on what more information I can provide are welcome. You can also try to build `pkgsStatic.openldap` in this nixpkgs [commit](f9e32f61282275eb5fa9064e08bbd0a92d1187de) -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Bug 9245] New: devel/programming needs rewrite
by openldap-its＠openldap.org 28 Jan '25

28 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=9245 Bug ID: 9245 Summary: devel/programming needs rewrite Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The information on the devel/programming web page is at least a decade out of date and needs a complete overhaul. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Issue 10084] New: Move away from DIGEST-MD5 as a default in the test suite
by openldap-its＠openldap.org 14 Jan '25

14 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=10084 Issue ID: 10084 Summary: Move away from DIGEST-MD5 as a default in the test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- cyrus-sasl seem on the verge or removing the DIGEST-MD5 mechanism from 2.2 onwards. As such we should update our defaults in a couple of our test scripts for master/2.7 at least. Are SCRAM mechanisms the go-to these days? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9827] New: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=9827 Issue ID: 9827 Summary: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: juergen.sprenger(a)swisscom.com Target Milestone: --- Hi, This is a feature request. I would like to be able to chooses between Argon2i, Argon2d and Argon2id in slappasswd like in argon2 command: # argon2 Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) | -k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)] Password is read from stdin Parameters: salt The salt to use, at least 8 characters -i Use Argon2i (this is the default) -d Use Argon2d instead of Argon2i -id Use Argon2id instead of Argon2i -t N Sets the number of iterations to N (default = 3) -m N Sets the memory usage of 2^N KiB (default 12) -k N Sets the memory usage of N KiB (default 4096) -p N Sets parallelism to N threads (default 1) -l N Sets hash output length to N bytes (default 32) -e Output only encoded hash -r Output only the raw bytes of the hash -v (10|13) Argon2 version (defaults to the most recent version, currently 13) -h Print argon2 usage Example: /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so i" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so d" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so id" -s secret Best regards Juergen Sprenger -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9952] New: Crash on exit with OpenSSL 3
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=9952 Issue ID: 9952 Summary: Crash on exit with OpenSSL 3 Product: OpenLDAP Version: 2.6.2 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: artur.zaprzala(a)gmail.com Target Milestone: --- A program using libldap will crash on exit after using SSL connection. How to reproduce on CentOS 9: Uncomment the following lines in /etc/pki/tls/openssl.cnf: [provider_sect] legacy = legacy_sect [legacy_sect] activate = 1 Run the command (you must enter a valid LDAP server address): python3 -c "import ldap; ldap.initialize('ldaps://<LDAP SERVER ADDRESS>').whoami_s()" Another example (no server required): python3 -c "import ctypes; ctypes.CDLL('libldap.so.2').ldap_pvt_tls_init_def_ctx(0)" Results: Segmentation fault (core dumped) Backtrace from gdb: Program received signal SIGSEGV, Segmentation fault. 0 ___pthread_rwlock_rdlock (rwlock=0x0) at pthread_rwlock_rdlock.c:27 1 0x00007ffff7c92f3d in CRYPTO_THREAD_read_lock (lock=<optimized out>) at crypto/threads_pthread.c:85 2 0x00007ffff7c8b126 in ossl_lib_ctx_get_data (ctx=0x7ffff7eff540 <default_context_int.lto_priv>, index=1, meth=0x7ffff7eb8a00 <provider_store_method.lto_priv>) at crypto/context.c:398 3 0x00007ffff7c98bea in get_provider_store (libctx=<optimized out>) at crypto/provider_core.c:334 4 ossl_provider_deregister_child_cb (handle=0x5555555ed620) at crypto/provider_core.c:1752 5 0x00007ffff7c8bf2f in ossl_provider_deinit_child (ctx=0x5555555d2650) at crypto/provider_child.c:279 6 OSSL_LIB_CTX_free (ctx=0x5555555d2650) at crypto/context.c:283 7 OSSL_LIB_CTX_free (ctx=0x5555555d2650) at crypto/context.c:276 8 0x00007ffff7634af6 in legacy_teardown (provctx=0x5555555ee9f0) at providers/legacyprov.c:168 9 0x00007ffff7c9901b in ossl_provider_teardown (prov=0x5555555ed620) at crypto/provider_core.c:1477 10 ossl_provider_free (prov=0x5555555ed620) at crypto/provider_core.c:683 11 0x00007ffff7c63956 in ossl_provider_free (prov=<optimized out>) at crypto/provider_core.c:668 12 evp_cipher_free_int (cipher=0x555555916c10) at crypto/evp/evp_enc.c:1632 13 EVP_CIPHER_free (cipher=0x555555916c10) at crypto/evp/evp_enc.c:1647 14 0x00007ffff7a6bc1d in ssl_evp_cipher_free (cipher=0x555555916c10) at ssl/ssl_lib.c:5925 15 ssl_evp_cipher_free (cipher=0x555555916c10) at ssl/ssl_lib.c:5915 16 SSL_CTX_free (a=0x555555ec1020) at ssl/ssl_lib.c:3455 17 SSL_CTX_free (a=0x555555ec1020) at ssl/ssl_lib.c:3392 18 0x00007fffe95edb89 in ldap_int_tls_destroy (lo=0x7fffe9616000 <ldap_int_global_options>) at /usr/src/debug/openldap-2.6.2-1.el9_0.x86_64/openldap-2.6.2/libraries/libldap/tls2.c:104 19 0x00007ffff7fd100b in _dl_fini () at dl-fini.c:138 20 0x00007ffff7873475 in __run_exit_handlers (status=0, listp=0x7ffff7a11658 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:113 21 0x00007ffff78735f0 in __GI_exit (status=<optimized out>) at exit.c:143 22 0x00007ffff785be57 in __libc_start_call_main (main=main@entry=0x55555556aa20 <main>, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2b8) at ../sysdeps/nptl/libc_start_call_main.h:74 23 0x00007ffff785befc in __libc_start_main_impl (main=0x55555556aa20 <main>, argc=4, argv=0x7fffffffe2b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2a8) at ../csu/libc-start.c:409 24 0x000055555556b575 in _start () The problem is that ldap_int_tls_destroy() is called after the clean up of libssl. On program exit, at first default_context_int is cleaned up (OPENSSL_cleanup() was registered with atexit()): 0 ossl_lib_ctx_default_deinit () at crypto/context.c:196 1 OPENSSL_cleanup () at crypto/init.c:424 2 OPENSSL_cleanup () at crypto/init.c:338 3 0x00007ffff7873475 in __run_exit_handlers (status=0, listp=0x7ffff7a11658 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:113 4 0x00007ffff78735f0 in __GI_exit (status=<optimized out>) at exit.c:143 5 0x00007ffff785be57 in __libc_start_call_main (main=main@entry=0x55555556aa20 <main>, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2c8) at ../sysdeps/nptl/libc_start_call_main.h:74 6 0x00007ffff785befc in __libc_start_main_impl (main=0x55555556aa20 <main>, argc=4, argv=0x7fffffffe2c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2b8) at ../csu/libc-start.c:409 7 0x000055555556b575 in _start () Then ossl_lib_ctx_get_data() tries to use default_context_int.lock, which is NULL. ldap_int_tls_destroy() is called by ldap_int_destroy_global_options(), registered by "__attribute__ ((destructor))". It seems that shared library destructors are always called before functions registered with atexit(). A solution may be to modify libraries/libldap/init.c to use atexit() instead of "__attribute__ ((destructor))". atexit() manual page says: "Since glibc 2.2.3, atexit() can be used within a shared library to establish functions that are called when the shared library is unloaded.". Functions registered with atexit() are called in the reverse order of their registration, so libssl must by initialized before libldap. If the order is wrong, libldap should detect it somehow and exit with abort(). -- You are receiving this mail because: You are on the CC list for the issue.

1 29

[Issue 10155] New: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10155 Issue ID: 10155 Summary: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: doug.leavitt(a)oracle.com Target Milestone: --- A customer reported core dumps in ldapsearch which has been tracked to the the improper use of the -F and -T options. The customer confirmed removing the invalid -F and -T options from their script eliminated the core dumps. The CLI arguments of the failing ldapsearch look like: ldapsearch <good CLI args> -F , -T u <good filter and attr args> The good CLI args include proper uses of -H... -x -D ... -w ... -b ... -s ... The good filter and attrs are also valid CLI inputs. The "bad" args are <sp>-F<sp><COMMA><sp>-T<sp>-u<sp> The -u is also valid but it is consumed as a directory name of -T From man page and code review the the -F argument is supposed to be a valid URL. and the -T argument is supposed to be a valid directory The core file output indicates that main calls free after the search takes place. The location is believed to be here: 1658 if ( urlpre != NULL ) { 1659 if ( def_urlpre != urlpre ) 1660 free( def_urlpre ); <--------- 1661 free( urlpre ); 1662 } ... 1672 tool_exit( ld, rc ); ... This is the first example of the use of -F we have seen so it is unclear how this should be fixed. But code review of ldapsearch.c and common.c exposed a few weaknesses that could help in addressing the issue. Observed weaknesses: The getopt processing code for -T does not check that the arg is actually a directory and fail/error when bad input is provided. Perhaps at least an access(2) check should be performed? It is unclear if -F should only accept file:// URLs. The existing code does not sufficiently check any URL format instead it processes the argument by looking for the first '/' [no error checking] and determine the remainder to be a tmpdir location similar to the -T argument. So, Fuzz input of <COMMA> seems to eventually lead to the core files. It is unclear if -F and -T should be mutually exclusive or not. It seems like the fix to this issue is to add better error checking and to fail on FUZZ inputs. I defer a solution to upstream as it probably requires project direction I lack. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2024