openldap-bugs July 2020

openldap-bugs@openldap.org

2 participants
123 discussions

[Issue 9298] New: Solaris compilation errors of OpenLDAP 2.4.50
by openldap-its＠openldap.org 22 Jul '20

22 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=9298 Issue ID: 9298 Summary: Solaris compilation errors of OpenLDAP 2.4.50 Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: mnesam(a)juniper.net Target Milestone: --- Created attachment 746 --> https://bugs.openldap.org/attachment.cgi?id=746&action=edit OpenLDAP 2.4.50 solaris compilation error Hi OpenLDAP team, We compiled OpenLDAP 2.4.50 with OpenSSL 1.1.1 version. It compiled without errors and worked fine. However,, the same is giving compilation errors , when compiled with openSSL 1.0.2. Is the compilation requirement to Openssl 1.1.1 mandatory for OpenLDAP 2.4.50 ? Regards, Merrylin Please find the complete log in the attachement. I'm getting the below errors during the compilation of openLDAP 2.4.50 with OpenSSL 1.0.2 in Solaris 5.10: /usr/bin/gcc -m64 -m64 -o apitest apitest.o -L/export/local/mvel/workspace/openldap_1507/openssl-1.0.2q/ -L/export/local/mvel/workspace/openldap_1507/krb5-1.18.1/src/lib/ -L/export/local/mvel/workspace/openldap_1507/krb5-1.18.1/src/lib/gssapi/ -L/export/local/mvel/workspace/openldap_1507/cyrus-sasl-2.1.27/lib/.libs/ -L/export/local/mvel/workspace/openldap_1507/cyrus-sasl-2.1.27/plugins/.libs/ ./.libs/libldap.a /export/local/mvel/workspace/openldap_1507/openldap-2.4.50/libraries/liblber/.libs/liblber.a -L/export/local/mvel/workspace/openldap_1507/openssl-1.0.2q/lib -L/export/local/mvel/workspace/openldap_1507/krb5-1.18.1/src/lib -L/export/local/mvel/workspace/openldap_1507/krb5-1.18.1/src/lib/gssapi/lib ../../libraries/liblber/.libs/liblber.a ../../libraries/liblutil/liblutil.a /export/local/mvel/workspace/openldap_1507/cyrus-sasl-2.1.27/lib/.libs//libsasl2.so -ldl -lgss -lssl -lcrypto -lresolv -lgen -lnsl -lsocket -R/export/local/mvel/workspace/openldap_1507/cyrus-sasl-2.1.27/lib/.libs/ -R/usr/local/lib Undefined first referenced symbol in file SSL_CTX_set_options ./.libs/libldap.a(tls_o.o) OPENSSL_sk_num ./.libs/libldap.a(tls_o.o) BIO_meth_set_write ./.libs/libldap.a(tls_o.o) OPENSSL_sk_free ./.libs/libldap.a(tls_o.o) OPENSSL_sk_value ./.libs/libldap.a(tls_o.o) TLS_method ./.libs/libldap.a(tls_o.o) OPENSSL_init_ssl ./.libs/libldap.a(tls_o.o) BIO_meth_new ./.libs/libldap.a(tls_o.o) BIO_set_init ./.libs/libldap.a(tls_o.o) BIO_get_data ./.libs/libldap.a(tls_o.o) BIO_set_data ./.libs/libldap.a(tls_o.o) BIO_meth_set_create ./.libs/libldap.a(tls_o.o) ASN1_STRING_get0_data ./.libs/libldap.a(tls_o.o) OPENSSL_sk_new_null ./.libs/libldap.a(tls_o.o) X509_NAME_get0_der ./.libs/libldap.a(tls_o.o) BIO_meth_free ./.libs/libldap.a(tls_o.o) SSL_CTX_up_ref ./.libs/libldap.a(tls_o.o) BIO_meth_set_destroy ./.libs/libldap.a(tls_o.o) BIO_meth_set_gets ./.libs/libldap.a(tls_o.o) BIO_meth_set_ctrl ./.libs/libldap.a(tls_o.o) BIO_meth_set_puts ./.libs/libldap.a(tls_o.o) BIO_meth_set_read ./.libs/libldap.a(tls_o.o) ld: fatal: symbol referencing errors. No output written to apitest gmake[2]: *** [apitest] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9300] New: OpenLDAP 2.4.50 Dependency Details
by openldap-its＠openldap.org 22 Jul '20

22 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=9300 Issue ID: 9300 Summary: OpenLDAP 2.4.50 Dependency Details Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: muthaiyan1991(a)gmail.com Target Milestone: --- I have selected product OpenLDAP 2.4.50.. can you please answer the query? We compiled OpenLDAP 2.4.50 with OpenSSL 1.1.1 version. It compiled without errors and worked fine. However,, the same is giving compilation errors , when compiled with openSSL 1.0.2. Is the compilation requirement to Openssl 1.1.1 mandatory for OpenLDAP 2.4.50 ? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9297] New: memory leak in mdb_dn2entry()
by openldap-its＠openldap.org 21 Jul '20

21 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=9297 Issue ID: 9297 Summary: memory leak in mdb_dn2entry() Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Callers of mdb_dn2entry() expect that mdb_dn2entry( ..., Entry **e [out], match = 1 ) provides newborn Entry if and only if [mdb_dn2entry return value in {0, MDB_NOTFOUND}]. They are right with this, because any other error code makes asking for "matching entry" irrelevant. However, mdb_dn2entry does not anyhow restrict error code when generates a "matching" Entry: | int | mdb_dn2entry( | ... | struct berval *dn, | Entry **e, | ... | int matched ) | { | ... | int rc = mdb_dn2id( ..., dn, &id, ... ); | if ( rc ) { | if ( matched ) { | int rc2 = mdb_cursor_open( ..., "id2entry", &mc ); | if ( rc2 == MDB_SUCCESS ) { | mdb_id2entry( op, mc, id, e ); | mdb_cursor_close( mc ); | } | } | } else ... | ... | return rc; | } So, when [mdb_dn2id return value is NOT in {0, MDB_NOTFOUND}], the Entry will be allocated by mdb_id2entry and then leaked by a caller. Not exactly so. Will be leaked only by mdb_search() and by mdb_add(). It looks like that other callers of mdb_dn2entry() are, by chance, not affected by this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 8701] account usability control for password less logins
by openldap-its＠openldap.org 21 Jul '20

21 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=8701 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • c7b008ee by Ondřej Kuzník at 2020-07-21T10:48:47+01:00 ITS#8701 Fix documentation -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9296] New: OpenLDAP mishandles rpath and runpath tokens
by openldap-its＠openldap.org 20 Jul '20

20 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=9296 Issue ID: 9296 Summary: OpenLDAP mishandles rpath and runpath tokens Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: noloader(a)gmail.com Target Milestone: --- Hi Everyone, I'm building OpenLDAP 2.4.50 release tarball on multiple operating systems. I've noticed there's a couple of issues with rpaths and runpaths. I configure OpenLDAP it includes the following LDFLAGS: LDFLAGS: -Wl,-R,'$ORIGIN/../lib' -Wl,-R,/export/home/jwalton/tmp/ok2delete/lib When I audit the result programs and shared objects, I see two issues. First, the rpaths and runpaths have been reordered. Second, rpath and runpath tokens were not preserved. The tokens include $ORIGIN, $LIB and $PLATFORM (see the ld.so(8) man page). In fact, the rpath and runpath seem to have been expanded to nothing. This is from Solaris. /export/home/jwalton/tmp/ok2delete/lib/libldap-2.4.so.2.10.13: RUNPATH /export/home/jwalton/tmp/ok2delete/lib:/../lib RPATH /export/home/jwalton/tmp/ok2delete/lib:/../lib And: /export/home/jwalton/tmp/ok2delete/lib/libldap_r-2.4.so.2.10.13: RUNPATH /export/home/jwalton/tmp/ok2delete/lib:/../lib RPATH /export/home/jwalton/tmp/ok2delete/lib:/../lib Expanding '$ORIGIN/../lib' to '/../lib' is especially problematic. '/../lib' is just '/lib', so OpenLDAP is runtime linking to the wrong libraries, like like zLib 1.2.8 and Bzip 1.0.6. Libraries like zLib 1.2.8 and Bzip 1.0.6 have active CVEs against them. It is better to runtime link against the new libraries I provide. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9266] Replace custom hostname and IP address verification with OpenSSL API
by openldap-its＠openldap.org 17 Jul '20

17 Jul '20

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

1 0

[Issue 8376] Use getaddrinfo to resolve FQDN
by openldap-its＠openldap.org 15 Jul '20

15 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=8376 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9287 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9099] LMDB: range delete
by openldap-its＠openldap.org 15 Jul '20

15 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=9099 --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- (In reply to Markus from comment #2) > > Right, rebalancing would become quite a pain. > > Regarding re-balancing, maybe a pragmatic solution could be two phase > range-delete: > > 1) First, delete only those pages in the given range that will not trigger > re-balancing. > 2) Second, delete the remaining nodes in the range as is (causing > re-balancing). > > Another simplification might be to limit the page deletions to leaf pages. > I'd guess the speed-up would already be quite significant. > > > If you are interested, I could give it a shot. Just let me know. Without > more efficient range-deletes, we may have to look into workarounds. Thus, > I'd be happy to invest some time to solve that at the "core". You're welcome to try whatever approach. As long as it doesn't increase the code size too much, and you can document a significant speedup, it'll be considered. Going back to your original post, instead of using hierarchical keys you should be using separate named databases for each group. Then just use mdb_drop to delete a group. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9099] LMDB: range delete
by openldap-its＠openldap.org 15 Jul '20

15 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=9099 --- Comment #2 from Markus <markus(a)objectbox.io> --- > Right, rebalancing would become quite a pain. Regarding re-balancing, maybe a pragmatic solution could be two phase range-delete: 1) First, delete only those pages in the given range that will not trigger re-balancing. 2) Second, delete the remaining nodes in the range as is (causing re-balancing). Another simplification might be to limit the page deletions to leaf pages. I'd guess the speed-up would already be quite significant. If you are interested, I could give it a shot. Just let me know. Without more efficient range-deletes, we may have to look into workarounds. Thus, I'd be happy to invest some time to solve that at the "core". -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9290] New: Trying to add new config to Ldap
by openldap-its＠openldap.org 14 Jul '20

14 Jul '20

https://bugs.openldap.org/show_bug.cgi?id=9290 Issue ID: 9290 Summary: Trying to add new config to Ldap Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: koshlendra.singh(a)punchh.com Target Milestone: --- WHile i am trying to add new user config to the LDAP server getting following error: ldap_add: Invalid syntax (21) additional info: uidNumber: value #0 invalid per syntax Please share your ideas to getting resolve on this -- You are receiving this mail because: You are on the CC list for the issue.

1 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2020