openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#8303)
by nivanova＠symas.com 01 Feb '16

01 Feb '16

This is a multi-part message in MIME format. --------------010703030802080506060500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit A new version of the patch with all fixes is uploaded as ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160130.patch <ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch> --------------010703030802080506060500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> A new version of the patch with all fixes is uploaded as <br> <pre><a href="ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch">ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160130.patch</a></pre> </body> </html> --------------010703030802080506060500--

1 0

Re: (ITS#8365) test061 failing
by quanah＠zimbra.com 31 Jan '16

31 Jan '16

--On Sunday, January 31, 2016 5:24 PM +0000 ryan(a)openldap.org wrote: > Full_Name: Ryan Tandy > Version: 2.4.43 > OS: Debian > URL: > Submission from: (NULL) (24.68.37.4) > Submitted by: ryan > > > Testing RE24 discovered that test061 fails sometimes: > > ERROR: Entry 10 not removed on ldap://localhost:9012/! (RC=0) > > Quanah confirmed this with 2.4.43, and also found that 2.4.42 is not > affected. > > Reverting 683c03fb "ITS#8281 fix delta-mmr with interrupted refresh" > seems to cure it for me. I was thinking perhaps a timing issue, but even after giving it up to 55 seconds to replicate, I still hit failures: Running 53 of 500 iterations Running defines.sh Initializing server configurations Starting provider slapd on ldap://localhost:9011/ Starting forward1 slapd on ldap://localhost:9013/ Starting consumer slapd on ldap://localhost:9012/ Adding schema on ldap://localhost:9011/ Adding backend module on ldap://localhost:9011/... Adding schema on ldap://localhost:9012/ Adding backend module on ldap://localhost:9012/... Adding schema on ldap://localhost:9013/ Adding backend module on ldap://localhost:9013/... Adding database configuration on ldap://localhost:9011/ Populating provider on ldap://localhost:9011/ Adding database configuration on ldap://localhost:9013/ Adding database configuration on ldap://localhost:9012/ Using ldapsearch to check that ldap://localhost:9013/ received database... Using ldapsearch to check that ldap://localhost:9012/ received database... Waiting 1 seconds for slapd to receive database... Running 1 of 1 syncrepl initiation race tests... Stopping forwarders for add test Using ldapadd to add 10 entries on provider Starting forwarders again Using ldapadd to add 10 more entries on provider Checking replication to ldap://localhost:9013/ Checking replication to ldap://localhost:9012/ Stopping forwarders for add/delete test Using ldapadd to add 10 entries on provider Using ldapdelete to delete 10 entries on provider Starting forwarders again Using ldapadd to add 10 more entries on provider Using ldapdelete to delete 10 more entries on provider Checking replication to ldap://localhost:9013/ Checking replication to ldap://localhost:9012/ Waiting 1 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 2 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 3 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 4 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 5 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 6 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 7 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 8 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 9 seconds for ldap://localhost:9012/ to delete entry 10... Waiting 10 seconds for ldap://localhost:9012/ to delete entry 10... ERROR: Entry 10 not removed on ldap://localhost:9012/! (RC=0) Error found after 1 of 1 iterations Failed after 53 of 500 iterations -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8366) test061 failing
by ryan＠nardis.ca 31 Jan '16

31 Jan '16

Closed the duplicate, sorry for the noise.

1 0

(ITS#8366) test061 failing
by ryan＠openldap.org 31 Jan '16

31 Jan '16

Full_Name: Ryan Tandy Version: 2.4.43 OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Testing RE24 discovered that test061 fails sometimes: ERROR: Entry 10 not removed on ldap://localhost:9012/! (RC=0) Quanah confirmed this with 2.4.43, and also found that 2.4.42 is not affected. Reverting 683c03fb "ITS#8281 fix delta-mmr with interrupted refresh" seems to cure it for me.

1 0

(ITS#8365) test061 failing
by ryan＠openldap.org 31 Jan '16

31 Jan '16

1 0

Re: (ITS#8364) [PATCH] back-meta idassert-bind tls_reqcert=never bug
by mohammad＠securiteam.io 31 Jan '16

31 Jan '16

Oh, thanks for clearing up the confusion, then is there anyway to prevent openldap from sending its server certificate as a client one when connecting to the meta target? I mean other than changing the TLSVerifyClient on the remote host as we don't have access to do this. Regards, Quoting Howard Chu <hyc(a)symas.com>: > mohammad(a)securiteam.io wrote: >> Full_Name: Mohammad Nweider >> Version: master >> OS: Redhat Linux >> URL: >> https://www.securiteam.io/contribs/openldap/mohammad-20160131-0001-fix-back… >> Submission from: (NULL) (89.100.154.148) >> >> >> Hello, >> >> We've found a small bug when trying to run openldap with meta >> backend, what we >> were trying to achieve is to have our server listens on ssl/tls port and to >> communicate with the meta targets over ssl/tls as well, but due to >> the fact that >> we're using a self-signed certificate and we don't have access to manage the >> meta targets, we wanted to skip the client certificate verification when >> connecting to the meta targets, so we tried adding idassert-bind >> tls_reqcert=never to our meta config for this purpose, but unfortunately it >> didn't work as expected. > > There is no bug here. The tls_reqcert setting controls whether the > local node requires the remote target to provide a valid server > certificate. It has nothing to do with client certificates at all. > >> Whenever openldap has a certificate/key either in >> TLSCertificateFile/TLSCertificateKeyFile or in idassert-bind >> tls_cert/tls_key >> settings, it completely ignores tls_reqcert in idassert-bd%d! > > Because the reqcert setting has nothing to do with this. > > Closing this ITS. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8364) [PATCH] back-meta idassert-bind tls_reqcert=never bug
by hyc＠symas.com 31 Jan '16

31 Jan '16

mohammad(a)securiteam.io wrote: > Full_Name: Mohammad Nweider > Version: master > OS: Redhat Linux > URL: https://www.securiteam.io/contribs/openldap/mohammad-20160131-0001-fix-back… > Submission from: (NULL) (89.100.154.148) > > > Hello, > > We've found a small bug when trying to run openldap with meta backend, what we > were trying to achieve is to have our server listens on ssl/tls port and to > communicate with the meta targets over ssl/tls as well, but due to the fact that > we're using a self-signed certificate and we don't have access to manage the > meta targets, we wanted to skip the client certificate verification when > connecting to the meta targets, so we tried adding idassert-bind > tls_reqcert=never to our meta config for this purpose, but unfortunately it > didn't work as expected. There is no bug here. The tls_reqcert setting controls whether the local node requires the remote target to provide a valid server certificate. It has nothing to do with client certificates at all. > Whenever openldap has a certificate/key either in > TLSCertificateFile/TLSCertificateKeyFile or in idassert-bind tls_cert/tls_key > settings, it completely ignores tls_reqcert in idassert-bd%d! Because the reqcert setting has nothing to do with this. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8364) [PATCH] back-meta idassert-bind tls_reqcert=never bug
by mohammad＠securiteam.io 31 Jan '16

31 Jan '16

Full_Name: Mohammad Nweider Version: master OS: Redhat Linux URL: https://www.securiteam.io/contribs/openldap/mohammad-20160131-0001-fix-back… Submission from: (NULL) (89.100.154.148) Hello, We've found a small bug when trying to run openldap with meta backend, what we were trying to achieve is to have our server listens on ssl/tls port and to communicate with the meta targets over ssl/tls as well, but due to the fact that we're using a self-signed certificate and we don't have access to manage the meta targets, we wanted to skip the client certificate verification when connecting to the meta targets, so we tried adding idassert-bind tls_reqcert=never to our meta config for this purpose, but unfortunately it didn't work as expected. Whenever openldap has a certificate/key either in TLSCertificateFile/TLSCertificateKeyFile or in idassert-bind tls_cert/tls_key settings, it completely ignores tls_reqcert in idassert-bd%d! to reproduce you can just try to build your server with ssl/tls enabled, add the tls global/server settings: TLSCACertificateFile /usr/local/etc/openldap/cacert.pem TLSCertificateFile /usr/local/etc/openldap/servercrt.pem TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem add some meta backend targets over ldaps with idassert-bind tls_reqcert=never: database meta suffix "dc=foo,dc=com" uri "ldaps://a.bar.com/dc=foo,dc=com" suffixmassage "dc=foo,dc=com" "dc=bar,dc=org" idassert-bind tls_reqcert=never Enable debugging and try to run some queries against your meta db. You will see a client certificate is sent to the meta target even with tls_reqcert=never! The mplelest fix I could come up with is to add the certificate/key to the ssl context only when is_server or lo->ldo_tls_require_cert is not zero like in the attached patch. Please let me know if I'm misunderstanding something or if this use case can be solved/achieved without this patch. Thanks,

1 0

Re: (ITS#8353) OpenLDAP won't compile with OpenSSL 1.1.X
by hyc＠symas.com 30 Jan '16

30 Jan '16

Howard Chu wrote: > Howard Chu wrote: >> m-oldap(a)bodyfour.uk wrote: >>> Full_Name: Mitchell Blank >>> Version: 2.4.43 >>> OS: linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (80.169.198.86) >>> >>> >>> Recently a couple alpha releases for OpenSSL 1.1.X have been posted on >>> www.openssl.org with the request that software be tested against them prior to >>> release. >> >> Thanks for the report. There are clearly 2 issues the OpenSSL folks will have >> to resolve before this will work. >> >> https://mta.openssl.org/pipermail/openssl-dev/2016-January/004362.html >> https://mta.openssl.org/pipermail/openssl-dev/2016-January/004365.html > > The remaining unresolved issue is in their tracker at > https://rt.openssl.org/Ticket/Display.html?id=4274 > Resolved by commit 7ab507495b86371756575d606af556b4fd74e27a All building and working now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8363) LMDB Heap corruption in mdb_midl_shrink
by hyc＠openldap.org 27 Jan '16

27 Jan '16

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.228.22) Submitted by: hyc off-by-one error

1 0

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