openldap-bugs November 2024

openldap-bugs@openldap.org

1 participants
80 discussions

[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 10227] New: Asyncmeta will not reset a connection if a bind operation fails with LDAP_OTHER, leaving the connection in invalid state
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10227 Issue ID: 10227 Summary: Asyncmeta will not reset a connection if a bind operation fails with LDAP_OTHER, leaving the connection in invalid state Product: OpenLDAP Version: 2.6.8 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: --- The issue is difficult to reproduce, it can happen under heavy traffic if the target is configured to do a sasl bind with a custom saslmech. In any case, currently asyncmeta only resets the connection of the error is LDAP_UNAVAILABLE, which is incorrect. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10219] New: Modify of olcDisabled by removing and adding a value invokes db_open twice
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10219 Issue ID: 10219 Summary: Modify of olcDisabled by removing and adding a value invokes db_open twice 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: nivanova(a)symas.com Target Milestone: --- A database is enabled by default, and therefore a missing olcDisabled attribute is equivalent to a value of FALSE. This means that currently a modify operation that removes a olcDisabled value will invoke the db_open handler for that database, even if in the same modify operation a value of TRUE is added. A modify operation like this: dn: olcDatabase={1}asyncmeta,cn=config changetype: modify delete: olcDisabled olcDisabled: FALSE - add: olcDisabled olcDisabled: TRUE - will call both db_open and db_close. This could be potentially harmful if the backend type allocates memory on db_open like asyncmeta, for example. It is a rare case, but it is best to fix it just in case. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10224] New: tlso_session_pinning: return codes from EVP* calls are not checked; can result in crashes or undefined behavior in library
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10224 Issue ID: 10224 Summary: tlso_session_pinning: return codes from EVP* calls are not checked; can result in crashes or undefined behavior in library 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: yaneurabeya(a)gmail.com Target Milestone: --- EVP* calls made in tlso_session_pinning on lines 1189-1191 [1] are not checked when computing the digest which is eventually placed in `keyhash.bv_val` on line [2]. Not checking the EVP* calls can result in undefined behavior, e.g., a library crash with SIGBUS, SIGSEGV, etc, and/or incorrect results when analyzing `keyhash.bv_val` later. The calls should be checked to avoid this scenario. Reported by Coverity. 1. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… 2. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10253] New: Compile failure with GnuTLS and GCC 14 on 32-bit
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10253 Issue ID: 10253 Summary: Compile failure with GnuTLS and GCC 14 on 32-bit 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: ryan(a)openldap.org Target Milestone: --- Debian bug report: https://bugs.debian.org/1078822 tls_g.c fails to compile on 32-bit platforms with GCC 14: $ gcc --version gcc (Debian 14.2.0-2) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -dumpmachine i686-linux-gnu $ ./configure --disable-slapd --with-tls=gnutls [...] $ make [...] libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC -DPIC -o .libs/tls_g.o tls_g.c: In function ‘tlsg_session_pinning’: tls_g.c:971:57: error: passing argument 4 of ‘gnutls_fingerprint’ from incompatible pointer type [-Wincompatible-pointer-types] 971 | keyhash.bv_val, &keyhash.bv_len ) < 0 ) { | ^~~~~~~~~~~~~~~ | | | ber_len_t * {aka long unsigned int *} In file included from tls_g.c:44: /usr/include/gnutls/gnutls.h:2408:32: note: expected ‘size_t *’ {aka ‘unsigned int *’} but argument is of type ‘ber_len_t *’ {aka ‘long unsigned int *’} 2408 | size_t *result_size); | ~~~~~~~~^~~~~~~~~~~ make[2]: *** [Makefile:431: tls_g.lo] Error 1 It looks like the warning has always been emitted since the code was originally committed, but with GCC 14 it became an error. (See <https://gcc.gnu.org/gcc-14/porting_to.html>. The last successful Debian build used GCC 13.) Quoting from the Debian bug report: > ber_len_t is typedef'ed in openldap as unsigned LBER_LEN_T, which is > AC_DEFINED as long. I'm not sure what a static AC_DEFINE in configure.ac > achieves, but that's what we have. On the other side, we have size_t, > which happens to be 32bit. Bummer. I suggest passing the 4th argument as > a temporary variable of type size_t and copying it from/to the target > structure after validating that it fits. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10264] New: libpdap leaks dummy_lr data on NoD processing
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10264 Issue ID: 10264 Summary: libpdap leaks dummy_lr data on NoD processing Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When a NoD unsolicited response is being processed in try_read1msg, we use the dummy_lr on stack, but data copied onto it is never freed, so we leak it as we return. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10237] New: openldap-2.6.8 fails to build with GCC14 with [-Wint-conversion]
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10237 Issue ID: 10237 Summary: openldap-2.6.8 fails to build with GCC14 with [-Wint-conversion] Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: timo.gurr(a)gmail.com Target Milestone: --- Created attachment 1023 --> https://bugs.openldap.org/attachment.cgi?id=1023&action=edit openldap-2.6.8-build.log With GCC 14 I'm experiencing the following error trying to build openldap 2.6.8: [...] In file included from ../slap.h:55, from search.c:32: search.c: In function 'ldap_back_search': ../../../include/ldap_pvt.h:531:31: error: passing argument 3 of '__gmpz_add' makes pointer from integer without a cast [-Wint-conversion] 531 | mpz_add((mpr), (mpr), (mpv)) | ^~~~~ | | | int search.c:257:9: note: in expansion of macro 'ldap_pvt_mp_add' 257 | ldap_pvt_mp_add( li->li_ops_completed[ SLAP_OP_SEARCH ], 1 ); | ^~~~~~~~~~~~~~~ In file included from ../../../include/ldap_pvt.h:519: /usr/x86_64-pc-linux-gnu/include/gmp.h:633:51: note: expected 'mpz_srcptr' {aka 'const __mpz_struct *'} but argument is of type 'int' 633 | __GMP_DECLSPEC void mpz_add (mpz_ptr, mpz_srcptr, mpz_srcptr); | ^~~~~~~~~~ make[3]: *** [Makefile:331: search.lo] Error 1 make[2]: *** [Makefile:550: .backend] Error 1 make[1]: *** [Makefile:298: all-common] Error 1 make: *** [Makefile:319: all-common] Error 1 This is with GCC 14.1.0, switching to GCC 13.2.0 instead allows the build to succeed, I checked other distributions (already on GCC 14) and git for possible patches but couldn't find anything relevant. Complete build log is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10232] New: assert() at shutdown if a syncrepl session is in refresh
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10232 Issue ID: 10232 Summary: assert() at shutdown if a syncrepl session is in refresh Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When removing the last one, syncinfo_free() checks that there is no active refresh on the backend. This works if operating on olcSyncrepl values because refresh_finished is called where appropriate. However if we're shutting down, this is skipped to make sure we don't schedule a new task and that could lead to an assert failure if there indeed was a refresh in progress (the same probably applies when removing the DB). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10280] New: Combining positive & negated filters doesn't work with dynlist
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10280 Issue ID: 10280 Summary: Combining positive & negated filters doesn't work with dynlist Product: OpenLDAP Version: 2.5.18 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: code(a)pipoprods.org Target Milestone: --- The directory contains 3 users & 2 groups. user1 is in group1, user2 is in group2, user3 isn't is any group. Filter [1] matches users that are either: - member of group1 - member of group2 ✅ It returns user1 & user2 Filter [2] matches user that are: - not member of group1 nor group2 ✅ It returns user3 Filter [3] should match users that are either: - member of group1 - member of group2 - not member of group1 nor group2 ❌ It should return the 3 users but only returns users matched by the first part of the filter (whatever the first part, if we swap both parts we get the complementary search results) Filter [1]: (|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com)) Filter [2]: (!(|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com))) Filter [3]: (|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com)(!(|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com)))) Here's my dynlist config: ``` dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynListConfig olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames structuralObjectClass: olcDynListConfig entryUUID: 7df8328a-fd72-103e-82df-6fed25d5f6c8 creatorsName: cn=config createTimestamp: 20240902122741Z entryCSN: 20240902122741.257759Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20240902122741Z ``` Here's a LDIF to initialise directory contents: ``` dn: ou=example-groups,dc=example,dc=com changetype: add objectClass: organizationalUnit ou: example-groups dn: ou=example-users,dc=example,dc=com changetype: add objectClass: organizationalUnit ou: example-users dn: uid=user1,ou=example-users,dc=example,dc=com changetype: add objectClass: inetOrgPerson cn: User sn: One uid: user1 dn: uid=user2,ou=example-users,dc=example,dc=com changetype: add objectClass: inetOrgPerson cn: User sn: Two uid: user2 dn: uid=user3,ou=example-users,dc=example,dc=com changetype: add objectClass: inetOrgPerson cn: User sn: Three uid: user3 dn: cn=group1,ou=example-groups,dc=example,dc=com changetype: add objectClass: groupOfNames cn: group1 member: uid=user1,ou=example-users,dc=example,dc=com dn: cn=group2,ou=example-groups,dc=example,dc=com changetype: add objectClass: groupOfNames cn: group2 member: uid=user2,ou=example-users,dc=example,dc=com ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10287] New: Add test case for mdb_get
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10287 Issue ID: 10287 Summary: Add test case for mdb_get Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: ahmed.zaki(a)imperial.ac.uk Target Milestone: --- Added a new file mtest7.c which tests the export mdb_get(). -- You are receiving this mail because: You are on the CC list for the issue.

1 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2024