openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8914) OpenLDAP and OpenSSL v1.1.1
by quanah＠symas.com 21 Sep '18

21 Sep '18

--On Friday, September 21, 2018 9:46 PM +0000 quanah(a)symas.com wrote: > --On Thursday, September 13, 2018 1:20 PM +0000 nea.brown(a)threesl.com > wrote: > >> Full_Name: Neal Brown >> Version: 2.4.46 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.98.37.245) >> >> >> OpenLDAP will not configure for building against OpenSSL v1.1.1 due to >> SSLv3 being disabled. > > Please provide the configure options you used with OpenSSL v1.1.1 and > OpenLDAP, as I as able to build OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 > without issue. Hi Neal, See above. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8914) OpenLDAP and OpenSSL v1.1.1
by quanah＠symas.com 21 Sep '18

21 Sep '18

--On Thursday, September 13, 2018 1:20 PM +0000 nea.brown(a)threesl.com wrote: > Full_Name: Neal Brown > Version: 2.4.46 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.98.37.245) > > > OpenLDAP will not configure for building against OpenSSL v1.1.1 due to > SSLv3 being disabled. Please provide the configure options you used with OpenSSL v1.1.1 and OpenLDAP, as I as able to build OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 without issue. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8917) OpenLDAP
by quanah＠symas.com 21 Sep '18

21 Sep '18

--On Friday, September 21, 2018 10:59 AM +0000 mhonek(a)redhat.com wrote: > Hi Nancy, > > I'm not aware of RHEL7 shipping with OpenSSL-1.1, OpenLDAP is linked > with openssl-1.0.2 there. > > Anyway, please report all issues related to TLS in OpenLDAP in Red Hat > products to Red Hat Support or Bugzilla, first. Based on what I read in their report, they have an LDAP server (not OpenLDAP) that has TLS 1.3 support, and the ldapsearch binaries on their RedHat system won't negotiate TLS 1.3 with that server. This is not surprising, as TLS 1.3 support in OpenSSL is only in the 1.1.1 release series and OpenLDAP is not yet updated to link to OpenSSL 1.1.1 (See ITS#8914). I'm currently examining what's necessary for such support. I would not expect any OpenLDAP based ldapsearch binary to be able to negotiate TLS 1.3 at this time, and I definitely wouldn't expect any Linux distribution OpenLDAP based ldapsearch binary to support it for quite some time. GnuTLS also only recently added TLS 1.3 support in the 3.6.3 release as of July 2018, so this would not work in debian based distributions either unless running the very bleeding edge. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8917) OpenLDAP
by mhonek＠redhat.com 21 Sep '18

21 Sep '18

Hi Nancy, I'm not aware of RHEL7 shipping with OpenSSL-1.1, OpenLDAP is linked with openssl-1.0.2 there. Anyway, please report all issues related to TLS in OpenLDAP in Red Hat products to Red Hat Support or Bugzilla, first. Thanks! Regards. On Fri, Sep 21, 2018 at 11:21 AM <nanmor(a)126.com> wrote: > > Full_Name: Nancy Mo > Version: openldap-clients-2.4.44-15.el7_5.x86_64 > OS: Redhat 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (106.38.0.87) > > > Hi team, > > Linux server is redhat7, and installed Openssl-1.1.1 which is support for > TLS1.3。 > I tried to connect a LDAP server which is used TLS1.3, the openldap clien= t > connection failed, if the server setting change to TLS 1.2, it can connec= ted > successfully。 > By the way, use the openssl s_client -connect HOSTNAME.com:636, it will u= se TLS > 1.3, and connect successfully. > In the ldap.conf, I have set two parameters： > > TLS_CACERTDIR /etc/openldap/certs > TLS_REQCERT never > > Why the openldap client can not use TLS1.3? > > Thanks a lot. > > beat regards > > nancy > --=20 Mat=C3=BA=C5=A1 Hon=C4=9Bk Software Engineer Red Hat Czech

1 0

(ITS#8917) OpenLDAP
by nanmor＠126.com 21 Sep '18

21 Sep '18

Full_Name: Nancy Mo Version: openldap-clients-2.4.44-15.el7_5.x86_64 OS: Redhat 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.38.0.87) Hi team, Linux server is redhat7, and installed Openssl-1.1.1 which is support for TLS1.3。 I tried to connect a LDAP server which is used TLS1.3, the openldap client connection failed, if the server setting change to TLS 1.2, it can connected successfully。 By the way, use the openssl s_client -connect HOSTNAME.com:636, it will use TLS 1.3, and connect successfully. In the ldap.conf, I have set two parameters： TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT never Why the openldap client can not use TLS1.3? Thanks a lot. beat regards nancy

1 0

Re: (ITS#8916) MDB_VL32 in readonly causes MDB_CORRUPTED
by pierre.chambart＠ocamlpro.com 19 Sep '18

19 Sep '18

On 19/09/2018 17:35, Howard Chu wrote: > pierre.chambart(a)ocamlpro.com wrote: >> Full_Name: Pierre Chambart >> Version:=20 >> OS:=20 >> URL:=20 >> Submission from: (NULL) (185.194.234.133) >> >> >> We have been trying LMDB compiled with the MDB_VL32 flag and encounter= ed some >> MDB_CORRUPTED error that didn't occur without MDB_VL32. >> We could produce a minimal reproduction case: >> https://raw.githubusercontent.com/chambart/lmdb/vl32_readonly_fix/libr= aries/liblmdb/vl32_failure.c >> This is basically writing a key, reading it, writing something else th= en reading >> it again. >> >> After some investigation, this is how I understand what is happening: >> >> * The chunk being mapped for the first read contains 3 pages instead o= f the 16 >> pages that would be mapped without readonly. >> * The second write extend the size of the base to 5 pages >> * Finally the last read retrieve the mapped chunk from the first read,= which has >> size 3, but assumes that it has size 5, hence reading some random valu= e in >> memory past the end of the pages. >> >> It can be verified by asserting that id3.mcnt is larger than rem at th= e end of >> mdb_rpage_get, around this line: >> >> ok: >> p =3D (MDB_page *)((char *)id3.mptr + rem * env->me_psize); >> >> This does not seem to be the case. >> >> I made a dirty fix that seems to work. It's simply to remove those lin= es: >> >> /* don't map past last written page in read-only envs */ >> if ((env->me_flags & MDB_RDONLY) && pgno + MDB_RPAGE_CHUNK-1 >= >> txn->mt_last_pgno) >> id3.mcnt =3D txn->mt_last_pgno + 1 - pgno; >> else >> >> This seems to be some optimization that avoids mapping the 16 pages of= the >> chunk. But given that those pages are >> initialized, there doesn't seem to be much harm in mapping a few more = pages in >> that relatively rare situation. > Please check git history before assuming the code is an optimization. > > These lines prevent a crash on Windows. > Sorry, about that. Also I'm not suggesting that this is a proper fix, rather that this is so= me clue to understand the problem. I'm happy producing a patch if you indicate what kind of fix you would like. --=20 Pierre

1 0

Re: (ITS#8916) MDB_VL32 in readonly causes MDB_CORRUPTED
by hyc＠symas.com 19 Sep '18

19 Sep '18

pierre.chambart(a)ocamlpro.com wrote: > Full_Name: Pierre Chambart > Version: > OS: > URL: > Submission from: (NULL) (185.194.234.133) > > > We have been trying LMDB compiled with the MDB_VL32 flag and encountered some > MDB_CORRUPTED error that didn't occur without MDB_VL32. > We could produce a minimal reproduction case: > https://raw.githubusercontent.com/chambart/lmdb/vl32_readonly_fix/libraries… > This is basically writing a key, reading it, writing something else then reading > it again. > > After some investigation, this is how I understand what is happening: > > * The chunk being mapped for the first read contains 3 pages instead of the 16 > pages that would be mapped without readonly. > * The second write extend the size of the base to 5 pages > * Finally the last read retrieve the mapped chunk from the first read, which has > size 3, but assumes that it has size 5, hence reading some random value in > memory past the end of the pages. > > It can be verified by asserting that id3.mcnt is larger than rem at the end of > mdb_rpage_get, around this line: > > ok: > p = (MDB_page *)((char *)id3.mptr + rem * env->me_psize); > > This does not seem to be the case. > > I made a dirty fix that seems to work. It's simply to remove those lines: > > /* don't map past last written page in read-only envs */ > if ((env->me_flags & MDB_RDONLY) && pgno + MDB_RPAGE_CHUNK-1 > > txn->mt_last_pgno) > id3.mcnt = txn->mt_last_pgno + 1 - pgno; > else > > This seems to be some optimization that avoids mapping the 16 pages of the > chunk. But given that those pages are > initialized, there doesn't seem to be much harm in mapping a few more pages in > that relatively rare situation. Please check git history before assuming the code is an optimization. These lines prevent a crash on Windows. -- -- 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#8916) MDB_VL32 in readonly causes MDB_CORRUPTED
by pierre.chambart＠ocamlpro.com 19 Sep '18

19 Sep '18

Full_Name: Pierre Chambart Version: OS: URL: Submission from: (NULL) (185.194.234.133) We have been trying LMDB compiled with the MDB_VL32 flag and encountered some MDB_CORRUPTED error that didn't occur without MDB_VL32. We could produce a minimal reproduction case: https://raw.githubusercontent.com/chambart/lmdb/vl32_readonly_fix/libraries… This is basically writing a key, reading it, writing something else then reading it again. After some investigation, this is how I understand what is happening: * The chunk being mapped for the first read contains 3 pages instead of the 16 pages that would be mapped without readonly. * The second write extend the size of the base to 5 pages * Finally the last read retrieve the mapped chunk from the first read, which has size 3, but assumes that it has size 5, hence reading some random value in memory past the end of the pages. It can be verified by asserting that id3.mcnt is larger than rem at the end of mdb_rpage_get, around this line: ok: p = (MDB_page *)((char *)id3.mptr + rem * env->me_psize); This does not seem to be the case. I made a dirty fix that seems to work. It's simply to remove those lines: /* don't map past last written page in read-only envs */ if ((env->me_flags & MDB_RDONLY) && pgno + MDB_RPAGE_CHUNK-1 > txn->mt_last_pgno) id3.mcnt = txn->mt_last_pgno + 1 - pgno; else This seems to be some optimization that avoids mapping the 16 pages of the chunk. But given that those pages are initialized, there doesn't seem to be much harm in mapping a few more pages in that relatively rare situation. The patch is provided in https://github.com/chambart/lmdb/commit/52e57a392e91935efe6d57337da09f23e40… If you want to reproduce the bug you can use the https://github.com/chambart/lmdb/tree/vl32_readonly_fix which also contains the patch to the makefile to build in 32bits with MDB_VL32. Thanks a lot, hoping that this can be of some help.

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠nardis.ca 18 Sep '18

18 Sep '18

Made some good progress on this one this evening. The original issue this ITS is about is that gnutls_handshake() can, in some versions of GnuTLS, return GNUTLS_E_AGAIN even when the socket is blocking. Specifically, this happens in the case I described with a large CA list sent by the server. For slapd, the patch I committed is unfortunately completely wrong. It has been using non-blocking sockets forever, EAGAIN is expected and handled robustly -- or it was, until I introduced the busy-loop. For clients I'm still working on figuring out the right path forward. There is some EAGAIN handling conditional on LDAP_USE_NON_BLOCKING_TLS which itself is behind LDAP_DEVEL. However this code is meant for non-blocking sockets, and in my case it ends up stuck in poll() waiting for a notification that never arrives. In 2.4, ret == 1 simply falls into the success case and proceeds to send data without completing the handshake first. It's possible that what I actually want here is a (ret > 0) case in ldap_int_tls_start for when LDAP_USE_NON_BLOCKING_TLS is absent and ldap_int_tls_connect returns 1. (I'd also need to adapt the non-blocking path to be able to handle a blocking socket as well.) But it's also possible that gnutls_handshake() returning GNUTLS_E_AGAIN with a blocking socket is simply a GnuTLS bug that was introduced at some point. I still need to determine exactly when and why its behaviour changed. (It is still happening with 3.5.19.) In any case, my patch has to be reverted, as its impact (making slapd busy-loop) is obviously worse than the status quo (misbehaving clients in a specific case). I have pushed that revert now and will continue digging as time permits.

1 0

(ITS#8915) OpenLDAP and OpenSSL v1.1.1
by neal.brown＠threesl.com 13 Sep '18

13 Sep '18

Full_Name: Neal Brown Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.98.37.245) OpenLDAP will not configure for building against OpenSSL v1.1.1 due to SSLv3 being disabled.

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