openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

[Issue 9521] New: libldap doesn't configure TLS1.3 ciphersuites for OpenSSL
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9521 Issue ID: 9521 Summary: libldap doesn't configure TLS1.3 ciphersuites for OpenSSL Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- OpenSSL 1.1 uses a separate API for configuring TLSv1.3 cipher suites. The current code in libldap doesn't call this API so those suites are always left at their compiled-in default. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9559] New: ldap_modify manpage LDAPMod incorrect
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9559 Issue ID: 9559 Summary: ldap_modify manpage LDAPMod incorrect Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- ldap_modify(3) suggests that struct ldapmod has a mod_next parameter, where ldap.h defines no such thing, nor is it even mentioned in RFC1823 for what that's worth. So I think it is the manpage that needs updating. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

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

1 0

[Issue 9554] New: Finish retiring configure.in in OpenLDAP 2.5 and later
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9554 Issue ID: 9554 Summary: Finish retiring configure.in in OpenLDAP 2.5 and later Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Update configure.in to configure.ac for contrib modules: ./contrib/ldaptcl/configure.in ./contrib/ldapc++/configure.in -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9494] New: Segfault after modify olcDbMaxSize w/ autogroup
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9494 Issue ID: 9494 Summary: Segfault after modify olcDbMaxSize w/ autogroup Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: louis.chanouha(a)univ-toulouse.fr Target Milestone: --- Hello, Yet another crash when modifying olcDbMaxSize. Seems not to be related to other similar reports. autogroup works fine until : - attempt to modify olcDbMaxSize - attempt to modify olcAGattrSet (segfault to, need to delete the overlay and add it again) - do not rely on olcMemberOfMemberAD (extra memberof module) requested change --------------------------------------------: dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 4294967296 openldap logs -----------------------------------------------: 6046b5c3 ==> autogroup_db_close 6046b5c3 ==> autogroup_db_close 6046b5c3 mdb_db_open: database "dc=domain,dc=fr": dbenv_open(/var/lib/ldap). 6046b5c3 ==> autogroup_db_open 6046b5c3 ==> autogroup_build_def_filter put_filter: "(objectClass=groupOfURLs)" put_filter: simple put_simple_filter: "objectClass=groupOfURLs" ber_scanf fmt ({mm}) ber: 6046b5c3 => mdb_search 6046b5c3 mdb_dn2entry("dc=domain,dc=fr") 6046b5c3 => mdb_dn2id("dc=domain,dc=fr") 6046b5c3 <= mdb_dn2id: got id=0x1 6046b5c3 => mdb_entry_decode: 6046b5c3 <= mdb_entry_decode 6046b5c3 search_candidates: base="dc=domain,dc=fr" (0x00000001) scope=2 6046b5c3 => mdb_equality_candidates (objectClass) 6046b5c3 => key_read 6046b5c3 <= mdb_index_read: failed (-30798) 6046b5c3 <= mdb_equality_candidates: id=0, first=0, last=0 6046b5c3 => mdb_equality_candidates (objectClass) 6046b5c3 => key_read 6046b5c3 <= mdb_index_read 5 candidates 6046b5c3 <= mdb_equality_candidates: id=5, first=18173, last=18177 6046b5c3 mdb_search_candidates: id=5 first=18173 last=18177 6046b5c3 => mdb_entry_decode: 6046b5c3 <= mdb_entry_decode 6046b5c3 ==> autogroup_group_add_cb <cn=cxxx,ou=groups,dc=domain,dc=fr> 6046b5c3 ==> autogroup_add_group <cn=xxx,ou=groups,dc=domain,dc=fr> Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7feb7d42c700 (LWP 37453)] GDB dump -------------------------------------- (gdb) info frame Stack level 0, frame at 0x7feb7d297fd0: rip = 0x55b4569bcba0 in dnMatch; saved rip = 0x7feb9e5f768b called by frame at 0x7feb7d298070 Arglist at 0x7feb7d297f88, args: Locals at 0x7feb7d297f88, Previous frame's sp is 0x7feb7d297fd0 Saved registers: rbx at 0x7feb7d297f98, rbp at 0x7feb7d297fa0, r12 at 0x7feb7d297fa8, r13 at 0x7feb7d297fb0, r14 at 0x7feb7d297fb8, r15 at 0x7feb7d297fc0, rip at 0x7feb7d297fc8 (gdb) bt #0 0x000055b4569bcba0 in dnMatch () #1 0x00007feb9e5f768b in ?? () from /usr/lib/ldap/autogroup.so.0 #2 0x00007feb9e5f98fb in ?? () from /usr/lib/ldap/autogroup.so.0 #3 0x000055b4569b6eb8 in ?? () #4 0x000055b4569b8a31 in slap_send_search_entry () #5 0x00007feb9e63dbf6 in mdb_search () from /usr/lib/ldap/back_mdb-2.4.so.2 #6 0x000055b456a16c68 in overlay_op_walk () #7 0x000055b456a16d97 in ?? () #8 0x00007feb9e5f9be0 in ?? () from /usr/lib/ldap/autogroup.so.0 #9 0x000055b456a15dd8 in ?? () #10 0x00007feb9e632eb8 in ?? () from /usr/lib/ldap/back_mdb-2.4.so.2 #11 0x000055b4569908b6 in ?? () #12 0x000055b4569be8aa in fe_op_modify () #13 0x000055b4569c0930 in do_modify () #14 0x000055b4569a66ed in ?? () #15 0x000055b4569a722c in ?? () #16 0x00007feb9fa5ea03 in ?? () from /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #17 0x00007feb9f990609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #18 0x00007feb9f8b7293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 cn=config overlays ---------------------------------- 22 olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf 23 olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=orga_default,ou=Policies,dc=domain,dc=fr olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: TRUE olcPPolicyForwardUpdates: TRUE 24 olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {2}syncprov 25 olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf objectClass: olcConfig olcOverlay: {3}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member 26 olcOverlay={4}autogroup,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAutomaticGroups olcOverlay: {4}autogroup olcAGattrSet: {0}groupOfURLs memberURL member olcAGmemberOfAd: memberOf 27 olcOverlay={5}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf objectClass: olcConfig olcOverlay: {5}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfURLs olcMemberOfMemberAD: member 28 olcOverlay={6}autogroup,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAutomaticGroups olcOverlay: {6}autogroup olcAGattrSet: {0}groupOfURLs memberUidURL memberUid -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 9561] New: Error doing 'make test': fails on 'test001-slapadd for mdb' test
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9561 Issue ID: 9561 Summary: Error doing 'make test': fails on 'test001-slapadd for mdb' test Product: OpenLDAP Version: 2.5.4 Hardware: x86_64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: sydbarrett74(a)gmail.com Target Milestone: --- FreeBSD 13.0 x86_64 I was attempting to build the latest version in the master git branch and when I issued the 'gmake test' command, I got the following errors: >>>>> Starting test001-slapadd for mdb... running defines.sh Running slapadd to build slapd database... Fatal error 'mutex 0x801018040 own 0x0 is on list 0x5952414e49422d58 0x312e312e' at line 154 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0) Abort trap (core dumped) slapadd failed (134)! >>>>> test001-slapadd failed for mdb after 1 seconds (exit 134) gmake[2]: *** [Makefile:301: mdb-yes] Error 134 gmake[2]: Leaving directory '/usr/home/bsduser/openldap/tests' gmake[1]: *** [Makefile:287: test] Error 2 gmake[1]: Leaving directory '/usr/home/bsduser/openldap/tests' gmake: *** [Makefile:299: test] Error 2 Please advise. TIA. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9548] New: argon2 module is not installed
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9548 Issue ID: 9548 Summary: argon2 module is not installed Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- 2.5.4, configured with --enable-argon2. 'make install' installs the argon2 man page, but not the module itself. Confirmed by Quanah. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9544] New: Compilation error when enabling SLAPI
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9544 Issue ID: 9544 Summary: Compilation error when enabling SLAPI Product: OpenLDAP Version: 2.5.4 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: jcarmona(a)vmware.com Target Milestone: --- OpenLDAP 2.5.4 fails to build when enabling SLAPI support for SLAPD: /bin/sh ../../../libtool --mode=compile cc -g -O2 -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c libtool: compile: cc -g -O2 -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c -fPIC -DPIC -o .libs/plugin.o plugin.c:37:16: error: unknown type name 'lt_dlhandle'; did you mean 'sa_handler'? SLAPI_FUNC *, lt_dlhandle * ); ^~~~~~~~~~~ sa_handler plugin.c: In function 'plugin_pblock_new': plugin.c:73:2: error: unknown type name 'lt_dlhandle'; did you mean 'sa_handler'? lt_dlhandle hdLoadHandle; ^~~~~~~~~~~ sa_handler plugin.c:103:7: warning: implicit declaration of function 'slapi_int_load_plugin'; did you mean 'slapi_int_get_plugins'? [-Wimplicit-function-declaration] rc = slapi_int_load_plugin( pPlugin, path, initfunc, 1, NULL, &hdLoadHandle ); ^~~~~~~~~~~~~~~~~~~~~ slapi_int_get_plugins plugin.c: At top level: plugin.c:557:2: error: unknown type name 'lt_dlhandle'; did you mean 'sa_handler'? lt_dlhandle *pLdHandle ) ^~~~~~~~~~~ sa_handler make[3]: *** [Makefile:388: plugin.lo] Error 1 make[3]: Leaving directory '/wig/openldap-2.5.4/servers/slapd/slapi' make[2]: *** [Makefile:524: slapi/libslapi.la] Error 2 make[2]: Leaving directory '/wig/openldap-2.5.4/servers/slapd' make[1]: *** [Makefile:300: all-common] Error 1 make[1]: Leaving directory '/wig/openldap-2.5.4/servers' make: *** [Makefile:321: all-common] Error 1 ---- In order to reproduce it, simply download the latest release and use the flag --enable-slapi when calling configure: $ wget https://www.openldap.org/software/download/OpenLDAP/openldap-release/openld… $ tar xfz openldap-2.5.4.tgz && cd openldap-2.5.4 $ ./configure --enable-slapi $ make depend $ make The compilation fails and binaries are not generated. This does not seem to happen on version 2.4.58, whose compilation runs smoothly with this flag activated. Additional Information: $ gcc --version gcc (Debian 8.3.0-6) 8.3.0 Copyright (C) 2018 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. $ uname -a Linux af3c371dbbbf 4.15.0-128-generic #131~16.04.1-Ubuntu SMP Wed Dec 9 17:33:47 UTC 2020 x86_64 GNU/Linux $ date Mon May 3 12:36:10 UTC 2021 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9541] New: Typos in ldap_pvt_gettimeofday() in libraries/libldap/util-int.c
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9541 Issue ID: 9541 Summary: Typos in ldap_pvt_gettimeofday() in libraries/libldap/util-int.c Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brecht(a)sanders.org Target Milestone: --- In openldap 2.544 there appear to be some typos in libraries/libldap/util-int.c - there is an int between the ldap_pvt_gettimeofday() function definition and the next curly brace - tv_spec is not a member of struct timeval, should be tv_sec patch -ulbf libraries/libldap/util-int.c << EOF @@ -300,3 +300,2 @@ ldap_pvt_gettimeofday( struct timeval *tv, void *unused ) -int { @@ -304,3 +303,3 @@ ldap_pvt_clock_gettime( 0, &ts ); - tv->tv_sec = ts.tv_spec; + tv->tv_sec = ts.tv_sec; tv->tv_usec = ts.tv_nsec / 1000; EOF -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9555] New: Introduce a default operations timeout for back-asyncmeta
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9555 Issue ID: 9555 Summary: Introduce a default operations timeout for back-asyncmeta Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Currently, if no operation timeout is configured, the default asyncmeta behavior is to have no timeout. This is potentially unsafe - if for some reason a target server does not return a response, the operation will stay in the queue until the connection is reset due to some network error (idle-timeout is not honored if there are pending operations). In the case of many such operations, the queues can get filled up and asyncmeta will become unable to process new operations for some time. Therefore, a setting of "0" should be used carefully and with intent. To prevent accidental configuration of 0, the default operations timeout should be a value larger than 0. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs