openldap-bugs August 2020

openldap-bugs@openldap.org

2 participants
185 discussions

[Issue 9054] Add support for multiple EECDH curves
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9054 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 9135] mdb index corruption during legitimate delete
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9135 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 9329] New: Intermittent panic: Assertion failed: !BER_BVISNULL( src ), file memory.c, line 705
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9329 Issue ID: 9329 Summary: Intermittent panic: Assertion failed: !BER_BVISNULL( src ), file memory.c, line 705 Product: OpenLDAP Version: 2.4.51 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- While testing openLDAP 2.4.51 with test target on Sparc the following issue was seen with 32bit build. >>>>> Starting test050-syncrepl-multiprovider for mdb... running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Inserting syncprov overlay on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Configuring syncrepl on server 2... Starting server 3 on TCP/IP port 9013... Using ldapsearch to check that server 3 is running... Configuring syncrepl on server 3... Starting server 4 on TCP/IP port 9014... Using ldapsearch to check that server 4 is running... Configuring syncrepl on server 4... Adding schema and databases on server 1... ldapadd modify for database config (255)! >>>>> test050-syncrepl-multiprovider failed for mdb The part of the test script which is failing is: echo "Adding schema and databases on server 1..." $LDAPADD -D cn=config -H $URI1 -y $CONFIGPWF <<EOF >>$TESTOUT 2>&1 include: file://$ABS_SCHEMADIR/core.ldif include: file://$ABS_SCHEMADIR/cosine.ldif include: file://$ABS_SCHEMADIR/inetorgperson.ldif include: file://$ABS_SCHEMADIR/openldap.ldif include: file://$ABS_SCHEMADIR/nis.ldif EOF RC=$? if test $RC != 0 ; then echo "ldapadd failed for schema config ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi Notes on script. - KILLSERVERS : unset. set to "no" to keep servers alive. - LDAPADD : comes from tests/scripts/defines.sh LDAPADD="$CLIENTDIR/ldapmodify -a $TOOLPROTO $TOOLARGS" - TESTOUT : also from defines.sh ./build/sparcv7/tests/testrun/test.out test.out contains modifying entry "cn=config" adding new entry "olcOverlay=syncprov,olcDatabase={0}config,cn=config" modifying entry "olcDatabase={0}config,cn=config" modifying entry "olcDatabase={0}config,cn=config" modifying entry "olcDatabase={0}config,cn=config" modifying entry "olcDatabase={0}config,cn=config" adding new entry "cn=core,cn=schema,cn=config" adding new entry "cn=cosine,cn=schema,cn=config" adding new entry "cn=inetorgperson,cn=schema,cn=config" adding new entry "cn=openldap,cn=schema,cn=config" adding new entry "cn=nis,cn=schema,cn=config" adding new entry "olcDatabase={1}mdb,cn=config" adding new entry "olcOverlay=syncprov,olcDatabase={1}mdb,cn=config" ldap_result: Can't contact LDAP server (-1) modifying entry "olcDatabase={1}mdb,cn=config" slapd log, ./build/sparcv7/tests/testrun/slapd.1.log contains ber_scanf fmt ({e{m[W]}}) ber: ** ld fb0410 Outstanding Requests: 5f3e9d3c >>> dnPrettyNormal: <olcDatabase={1}mdb,cn=config> * msgid 2, origid 2, status InProgress => ldap_bv2dn(olcDatabase={1}mdb,cn=config,0) outstanding referrals 0, parent count 0 <= ldap_bv2dn(olcDatabase={1}mdb,cn=config)=0 ld fb0410 request count 1 (abandoned 0) => ldap_dn2bv(272) <= ldap_dn2bv(olcDatabase={1}mdb,cn=config)=0 read1msg: ld fa7f60 msgid 2 all 0 <= ldap_bv2dn(cn=config)=0 ber_get_next => ldap_dn2bv(272) => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 <= ldap_dn2bv(olcDatabase={1}mdb,cn=config)=0 5f3e9d3c <<< dnNormalize: <cn=config> 5f3e9d3c <<< dnPrettyNormal: <olcDatabase={1}mdb,cn=config>, <olcDatabase={1}mdb,cn=config> 5f3e9d3c conn=1011 op=1 modifications: 5f3e9d3c >>> dnNormalize: <cn=config> 5f3e9d3c add: olcDbIndex => ldap_bv2dn(cn=config,0) 5f3e9d3c multiple values 5f3e9d3c conn=1011 op=1 MOD dn="olcDatabase={1}mdb,cn=config" <= ldap_bv2dn(cn=config)=0 5f3e9d3c conn=1011 op=1 MOD attr=olcDbIndex ,** ld fb0410 Response Queue: => ldap_dn2bv(272) 5f3e9d3c syncprov_matchops: sid 004 fscope 1 rc 6 <= ldap_dn2bv(cn=config)=0 5f3e9d3c syncprov_matchops: sid 003 fscope 1 rc 6 5f3e9d3c <<< dnNormalize: <cn=config> 5f3e9d3c slap_queue_csn: queueing 10316d0 20200820155644.190066Z#000000#001#000000 5f3e9d3c <= str2entry(cn=config) -> 0x1076964 Empty ld fb0410 response count 0 ldap_chkResponseList ld fb0410 msgid 2 all 0 ldap_chkResponseList returns ld fb0410 NULL ldap_int_select ber_get_next: tag 0x30 len 35 contents: read1msg: ld fa7f60 msgid 2 message type intermediate ldap_parse_intermediate ber_scanf fmt ({) ber: ber_scanf fmt (a) ber: ber_scanf fmt (O) ber: 5f3e9d3c do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - REFRESH_DELETE ber_scanf fmt (t{) ber: ber_scanf fmt (}) ber: read1msg: ld 103e468 msgid 2 all 0 Assertion failed: !BER_BVISNULL( src ), file memory.c, line 705 ber_get_next Core file stack is: $ mdb ./build/sparcv7/tests/testrun/srv1/core slapd:core> ::status debugging core file of slapd (32-bit) from slitheen file: /builds2/smarshal/openldap-2.4.51-master/components/openldap/build/sparcv7/servers/slapd/.libs/slapd initial argv: /builds2/smarshal/openldap-2.4.51-master/components/openldap/build/sparcv7/serv threading model: raw lwps status: process terminated by SIGABRT (Abort), pid=949186 uid=521808 code=-1 panic message: Assertion failed: !BER_BVISNULL( src ), file memory.c, line 705 slapd:core> $C e9ffef08 libc.so.1`__lwp_sigqueue+8(6, 0, ffffffef, ffffffec, e9ffef58, 5) e9ffef68 libc.so.1`abort+0x100(e9fff058, 1, ec124b18, 0, b18, 800) e9ffeff8 libc.so.1`_assert+0x68(ebe433a8, ebe4338c, 2c1, ffe8fdf3, ec124000, 170000) e9fff258 liblber-2.4.so.2.10.14`ber_bvreplace_x+0xd4(f84c00, 1ac00, 0, 4, 30303030, ebe5e000) e9fff2b8 merge_state+0x45c(1032230, 28, 102acc0, 1032340, 108787c, 3) e9fff320 check_syncprov+0x36c(e9fff978, 1032230, 102aca8, 10312c0, 102aca8, 29dcd8) e9fff490 do_syncrep2+0x26d4(e9fff978, 1032230, 0, 7acb8, 31, e9fff5f4) e9fff748 do_syncrepl+0x43c(f75a08, 10323d8, 0, f759f0, 1000, 1032340) e9fffd78 libldap_r-2.4.so.2.10.14`ldap_int_thread_pool_wrapper+0x2f8(ebede000, 3 , 1, f417d8, ebef018c, e9fffddc) e9ffff60 libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) slapd:core> -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9328] New: CLDAP ldap_result hangs if nobody listens on the port
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9328 Issue ID: 9328 Summary: CLDAP ldap_result hangs if nobody listens on the port Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: pbrezina(a)redhat.com Target Milestone: --- When using LDAP over UDP, calling ldap_result() hangs if there is nobody listening on the remote port. The problem is that it calls recvfrom() twice, the first attempt returns ECONNREFUSED but this is ignored. The seconds read then blocks/timeouts/returns EAGAIN depending on the sockets settings, however we know that we will never receive any data so it should return an error. See [1] poll([{fd=20, events=POLLIN|POLLPRI}], 1, 0) = 1 ([{fd=20, revents=POLLERR}]) recvfrom(20, 0x18dade0, 16256, 0, 0x18dad60, [128]) = -1 ECONNREFUSED (Connection refused) recvfrom(20, <unfinished ...>) = ? [1] https://git.openldap.org/pbrezina/openldap/-/blob/master/libraries/libldap/… -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9324] New: slapd can be stuck in REFRESH mode if a network error occurs
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9324 Issue ID: 9324 Summary: slapd can be stuck in REFRESH mode if a network error occurs Product: OpenLDAP Version: 2.4.51 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Found when a load balancer severed connection between a provider and consumers while the consumers were in REFRESH mode, they deadlocked. Also blocked the ability to update cn=config. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9318] New: RFC 6125 compliance (SANs-ID vs CN-ID)
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9318 Issue ID: 9318 Summary: RFC 6125 compliance (SANs-ID vs CN-ID) Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dar(a)xoe.solutions Target Milestone: --- > As noted, a client MUST NOT seek a match for a reference identifier > of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, > URI-ID, or any application-specific identifier types supported by the > client. It goes on > Therefore, if and only if the presented identifiers do not include a > DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types > supported by the client, then the client MAY as a last resort check > for a string whose form matches that of a fully qualified DNS domain > name in a Common Name field of the subject field (i.e., a CN-ID). If > the client chooses to compare a reference identifier of type CN-ID > against that string, it MUST follow the comparison rules for the DNS > domain name portion of an identifier of type DNS-ID, SRV-ID, or > URI-ID, as described under Section 6.4.1, Section 6.4.2, and > Section 6.4.3. Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (https://tools.ietf.org/html/rfc6125#section-6.4.4) > This is an Internet Standards Track document. Ldap still using CN-ID by default, in the presence of URI/DNS/SRV SANs is prohibited and not standards compliant. It _may_ only fall back to CN if non of those values is provided. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Bug 9249] New: A dollar sign ($) at the end of the 2nd argument of olcAuthzRegexp crashes slapd
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9249 Bug ID: 9249 Summary: A dollar sign ($) at the end of the 2nd argument of olcAuthzRegexp crashes slapd Product: OpenLDAP Version: 2.4.47 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- The following ldif, fed to ldapmodify, crashes slapd. dn: cn=config changetype: modify replace: olcAuthzRegexp olcAuthzRegexp: "^([^,]+),cn=PLAIN,cn=auth" "$1,ou=People,dc=example,dc=com$" Happens on Debian 10 with openldap 2.4.47 and RHEL 8 with openldap 2.4.46. Doing ldapmodify -d -1 seems to crash only 1 out of 3 times, but it always crashes without the -d -1. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Issue 3953] Enhancement - changelog module
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=3953 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 3953] Enhancement - changelog module
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=3953 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- The auditlog overlay generates something quite similar, and there's little value in supporting this at this point. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4685] Updated changelog overlay by Neil Dunbar
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=4685 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

← Newer
1
...
10
11
12
13
14
15
16
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2020