openldap-bugs August 2024

openldap-bugs@openldap.org

1 participants
54 discussions

[Bug 9219] New: Streamline tool API for 2.5
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9219 Bug ID: 9219 Summary: Streamline tool API for 2.5 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The current tool API is a mess and needs fixing for 2.5. This affects things like slapacl (The fix for bug#7920 was a kludge to deal with this, needs revisiting). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 9367] New: back-mdb: encryption support
by openldap-its＠openldap.org 14 Oct '24

14 Oct '24

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 7

[Bug 9204] New: slapo-constraint allows anyone to apply Relax control
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9204 Bug ID: 9204 Summary: slapo-constraint allows anyone to apply Relax control Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- slapo-constraint doesn't limit who can use the Relax control, beyond the global limits applied by slapd. In practice, for many modifications this means any configured constraints are advisory only. In my opinion this should be considered a bug, in design if not implementation. I expect many admins would not read the man page closely enough to realize the behaviour does technically adhere to the letter of what's written there. Either slapd should require manage privileges for the Relax control globally, or slapo-constraint should perform a check for manage privilege itself, like slapo-unique does. Quoting ando in https://bugs.openldap.org/show_bug.cgi?id=5705#c4: > Well, a user with "manage" privileges on related data could bypass > constraints enforced by slapo-constraint(5) by using the "relax" > control. The rationale is that a user with manage privileges could be > able to repair an entry that needs to violate a constraint for good > reasons. Note that the user: > > - must have enough privileges to do it (manage) > > - must inform the DSA that intends to violate the constraint (by using > the control) but such privileges are currently not being required. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Issue 10234] New: syncrepl does not reset the retrynum
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10234 Issue ID: 10234 Summary: syncrepl does not reset the retrynum Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- ``` syncrepl retry="5 10 30 +" ``` When replication fails with the above settings, syncrepl retries "10 times at 5 second intervals". Then, the retry count should be reset on the next replication failure. In actual, it does not reset. The behavior is as follows: ``` (first time replication failure) do_syncrepl: rid=001 rc -1 retrying (9 retries left) do_syncrepl: rid=001 rc -1 retrying (8 retries left) (resume replication) (second time replication failure) do_syncrepl: rid=001 rc -1 retrying (7 retries left) do_syncrepl: rid=001 rc -1 retrying (6 retries left) ``` -- 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 04 Oct '24

04 Oct '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 4

[Issue 10248] New: translucent + subordinate regression
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10248 Issue ID: 10248 Summary: translucent + subordinate regression Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mike(a)nolta.net Target Milestone: --- Created attachment 1027 --> https://bugs.openldap.org/attachment.cgi?id=1027&action=edit translucent + subordinate regression testcase, formatted for tests/data/regressions/ Hi, Attached please find a testcase for a regression we noticed in a translucent + subordinate slapd configuration. The test works in version 2.4.59, but fails in versions 2.5.5 and 2.6.8. In a nutshell, search results from the subordinate database aren't being returned, even though (judging by the logs) they appear to be found. Thanks, -Mike -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10249] New: slapo-nestgroup leak with non-nested groups
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10249 Issue ID: 10249 Summary: slapo-nestgroup leak with non-nested groups Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Searching for a member= of a group when no nesting is in place will leak memory. It seems to stem from a few `gi.gi_numDNs` tests that should most likely be against `gi.gi_DNs` instead. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

04 Oct '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 5

[Issue 10233] New: wrong idl intersection
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10233 Issue ID: 10233 Summary: wrong idl intersection 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: hamano(a)osstech.co.jp Target Milestone: --- The `mdb_idl_intersection()` and `wt_idl_intersection()` functions derived from back-bdb return wrong results. expect: [1, 3] ∩ [2] = [] actual: [1, 3] ∩ [2] = [2] -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

04 Oct '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 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2024