openldap-bugs September 2018

openldap-bugs@openldap.org

14 participants
37 discussions

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

22 Sep '18

Thanks for the response Quanah. You're right they're mentioning "some" LDAP server. And as you indirectly mentioned, with OpenSSL 1.0 the TLS 1.3 is not supported. However, I believe TLS 1.3 already works with OpenLDAP and OpenSSL. You might want to give a try to Docker image fedora:rawhide. I was able to successfully establish TLS 1.3 connection ldapsearch<->slapd. Tested with: openldap-2.4.46-8.fc30.x86_64 openssl-1.1.1-0.pre9.2.fc30.x86_64 HTH Best regards, Matus On Fri, Sep 21, 2018 at 8:23 PM Quanah Gibson-Mount <quanah(a)symas.com> wrot= e: > > --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 Linu= x > distribution OpenLDAP based ldapsearch binary to support it for quite som= e > time. GnuTLS also only recently added TLS 1.3 support in the 3.6.3 relea= se > 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> > --=20 Mat=C3=BA=C5=A1 Hon=C4=9Bk Software Engineer Red Hat Czech

1 0

(ITS#8919) common.c:2329: suspicious expression ?
by dcb314＠hotmail.com 22 Sep '18

22 Sep '18

Full_Name: David Binderman Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.65.83.114) common.c:2329:10: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] Source code is if ( !tool_ctrl_response[j].mask & tool_type ) { Maybe better code: if ( !(tool_ctrl_response[j].mask & tool_type) ) { I can recommend compiling the openldap product with the clang C/C++ compiler.

1 0

(ITS#8918) sasl.c:326: possible bad assignment ?
by dcb314＠hotmail.com 22 Sep '18

22 Sep '18

Full_Name: David Binderman Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.65.83.114) sasl.c:326:6: warning: equality comparison result unused [-Wunused-comparison] view +326 openldap/openldap-2.4.46/servers/slapd/sasl.c Source code is if ( !conn ) { rc == LDAP_SUCCESS; goto done; } Suggest new code if ( !conn ) { rc = LDAP_SUCCESS; goto done; }

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2018