openldap-bugs

openldap-bugs@openldap.org

1 participants
20891 discussions

[Issue 10266] New: Adopt broader RFC4511 NoD interpretation on lloadd's client side
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10266 Issue ID: 10266 Summary: Adopt broader RFC4511 NoD interpretation on lloadd's client side Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Server side, lloadd has long implemented a broad interpretation of NoD unsolicited response handling: when the message is issued, no new requests are accepted on the session however the client and server are both free to keep the session open if there are any operations that have not resolved yet. The server is still expected to close the connection as soon as no operations are still pending. This seems to interoperate with known clients. Those that want to will close the session immediately, unaware of this possibility, those that also want to interpret RFC 4511 this way can choose to wait for existing operations to resolve. This ticket is to track the lloadd's implementation of the client side of this - when receiving a NoD message, we don't close the connection immediately+unconditionally either but are willing to wait. Related functionality: - if connection was a bind connection processing a multi-stage SASL bind, the bind should fail if/when the client attempts to progress it - clients assigned to this connection through coherence at least 'connection' are also marked closing -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[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 10256] New: Custom attribute disappears after slapd restart
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10256 Issue ID: 10256 Summary: Custom attribute disappears after slapd restart Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: heinrich.blatt(a)googlemail.com Target Milestone: --- Hi, i want to use a custom attribute in my schema. I use that ldif: dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.2.840.113556.1.4.7000 NAME 'rfidtoken' DESC 'RFID Token' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) This i inject via ldapmodify. For the session it works, but after restarting slapd the attribute disappears. If i add it again via ldapmodify it is there for the session again. My /etc/ldap/slapd.d/cn=config/cn=schema.ldif contains the change. This seems related to #9066, however the documentation indicates that i can make the changes via ldapmodify persistent. What is the right approach there? What i can do to persist the change? Thanks in advance for support -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[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 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=7400 --- Comment #16 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • af4dfade by Quanah Gibson-Mount at 2024-10-04T21:53:57+00:00 ITS#7400 - Fix exattr to exattrs option -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs