openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8922) tls_o bug with OpenSSL 1.1.1
by norm.green＠gemtalksystems.com 01 Oct '18

01 Oct '18

Thank you Michael, you are correct. Somehow I missed the 2.4.46 release. This issue may be closed. Norm Green On 10/1/2018 2:38 AM, Michael Ströder wrote: > On 10/1/18 6:18 AM, norm.green(a)gemtalksystems.com wrote: >> Full_Name: Norman Green >> Version: 2.4.45 >> >> Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL >> 1.1.1 and the static initialization is now incorrect: > CHANGES of release 2.4.46 contains this: > > -------------------------- snip -------------------------- > OpenLDAP 2.4.46 Release (2018/03/22) > [..] > Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) > -------------------------- snip -------------------------- > > So your report might be a duplicate of this: > > https://www.openldap.org/its/index.cgi?findid=8791 > > Ciao, Michael.

1 0

Re: (ITS#8922) tls_o bug with OpenSSL 1.1.1
by michael＠stroeder.com 01 Oct '18

01 Oct '18

On 10/1/18 6:18 AM, norm.green(a)gemtalksystems.com wrote: > Full_Name: Norman Green > Version: 2.4.45 > > Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL > 1.1.1 and the static initialization is now incorrect: CHANGES of release 2.4.46 contains this: -------------------------- snip -------------------------- OpenLDAP 2.4.46 Release (2018/03/22) [..] Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) -------------------------- snip -------------------------- So your report might be a duplicate of this: https://www.openldap.org/its/index.cgi?findid=8791 Ciao, Michael.

1 0

(ITS#8922) tls_o bug with OpenSSL 1.1.1
by norm.green＠gemtalksystems.com 30 Sep '18

30 Sep '18

Full_Name: Norman Green Version: 2.4.45 OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.53.145.234) in tls_o.c, the function tlso_sb_setup has this code on line 833: bio = BIO_new( &tlso_bio_method ); which uses a statically allocated BIO_METHOD. Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL 1.1.1 and the static initialization is now incorrect: static BIO_METHOD tlso_bio_method = { ( 100 | 0x400 ), /* it's a source/sink BIO */ "sockbuf glue", tlso_bio_write, tlso_bio_read, tlso_bio_puts, tlso_bio_gets, tlso_bio_ctrl, tlso_bio_create, tlso_bio_destroy }; In 1.1.1, this (internal) SSL struct looks like this: struct bio_method_st { int type; char *name; int (*bwrite) (BIO *, const char *, size_t, size_t *); int (*bwrite_old) (BIO *, const char *, int); int (*bread) (BIO *, char *, size_t, size_t *); int (*bread_old) (BIO *, char *, int); int (*bputs) (BIO *, const char *); int (*bgets) (BIO *, char *, int); long (*ctrl) (BIO *, int, long, void *); int (*create) (BIO *); int (*destroy) (BIO *); long (*callback_ctrl) (BIO *, int, BIO_info_cb *); };

1 0

Re: (ITS#8918) sasl.c:326: possible bad assignment ?
by quanah＠symas.com 26 Sep '18

26 Sep '18

--On Saturday, September 22, 2018 11:11 AM +0000 dcb314(a)hotmail.com wrote: > Full_Name: David Binderman > Version: 2.4.46 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.65.83.114) Thanks for the report, this has been fixed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8921) Content Sync Refresh Required when provider accesslog is empty
by au＠hcsd.de 26 Sep '18

26 Sep '18

Full_Name: Stephan Austerm.hle Version: 2.4.46 OS: Linux (Debian unstable) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.20.232.53) Consumer slapd emits endless 5babd9c4 do_syncrep2: rid=001 (4096) Content Sync Refresh Required messages when the provider has an empty accesslog (because it was freshly setup and nothing has been added/updated since then). This issue was mentioned back in 2013 (see http://www.openldap.org/lists/openldap-technical/201301/msg00229.html) already but it looks like it was not reported. The provider likewise logs 5babd9cf conn=1000 op=60677 SRCH base="dc=company,dc=com" scope=2 deref=0 filter="(objectClass=*)" 5babd9cf conn=1000 op=60677 SRCH attr=* + 5babd9cf conn=1000 op=60677 SEARCH RESULT tag=101 err=0 nentries=0 text= for every attempt from the consumer to lookup records in the accesslog.

1 0

Re:Re: (ITS#8920) OpenLDAP
by nanmor＠126.com 26 Sep '18

26 Sep '18

------=_Part_106754_1961220656.1537947199160 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgUXVhbmFoo6wKVGhhbmtzIGEgbG90IGZvciB5b3VyIGhlbHAuIEkgd2lsbCB1cGdyYWRlIG15 IG9wZW5sZGFwIHRvIDIuNC40NiB2ZXJzaW9uIHRoZW4gaGF2ZSBhIHRyeS4gdGhhbmtzIGFnYWlu LgoKCmJlc3QgcmVnYXJkcywKbmFuY3kKCgoKCgpBdCAyMDE4LTA5LTI1IDA4OjU5OjIxLCAiUXVh bmFoIEdpYnNvbi1Nb3VudCIgPHF1YW5haEBzeW1hcy5jb20+IHdyb3RlOj4tLU9uIFR1ZXNkYXks IFNlcHRlbWJlciAyNSwgMjAxOCAxOjQ2IEFNICswMDAwIG5hbm1vckAxMjYuY29tIHdyb3RlOgo+ Cj4+IEZ1bGxfTmFtZTogTmFuY3kgTW8KPj4gVmVyc2lvbjogb3BlbmxkYXAtY2xpZW50cy0yLjQu NDQtMTUuZWw3XzUueDg2XzY0Cj4+IE9TOiBSZWRoYXQgNwo+PiBVUkw6IGZ0cDovL2Z0cC5vcGVu bGRhcC5vcmcvaW5jb21pbmcvCj4+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICgxMDYuMzguMC44 NykKPgo+SGVsbG8sCj4KPlRoZSBJVFMgc3lzdGVtIGlzIGZvciBidWcgcmVwb3J0cyBvbmx5LiAg UGxlYXNlIGRpcmVjdCB1c2FnZSBxdWVzdGlvbnMgdG8gCj50aGUgb3BlbmxkYXAtdGVjaG5pY2Fs IGxpc3QuICBJIHdpbGwgbm90ZSB0aGF0IEkndmUgdGVzdGVkIE9wZW5MREFQIDIuNC40NiAKPndp dGggYm90aCBzdGFydFRMUyBhbmQgTERBUFMgdXNpbmcgVExTIDEuMyB3aGVuIGNvbXBpbGVkIG9u IGJvdGggdGhlIHNlcnZlciAKPmFuZCBjbGllbnQgc2lkZSB3aXRoIE9wZW5TU0wgMS4xLjEgYW5k IGl0IHdvcmtlZCBjb3JyZWN0bHkuICBZb3Ugd2lsbCBuZWVkIAo+dG8gcHJvdmlkZSBzaWduaWZp Y2FudGx5IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgeW91ciBjb25maWd1cmF0aW9uL3NldHVwIAo+ d2hlbiBjb250YWN0aW5nIHRoZSBvcGVubGRhcC10ZWNobmljYWwgbGlzdCBmb3IgYW55IGZ1cnRo ZXIgYXNzaXN0YW5jZS4KPgo+SSB3b3VsZCBhbHNvIG5vdGUgdGhhdCBvZmZpY2lhbCBzdXBwb3J0 IGZvciBPcGVuU1NMIDEuMS4wIGFuZCBsYXRlciB3YXMgbm90IAo+YWRkZWQgdW50aWwgdGhlIE9w ZW5MREFQIDIuNC40NSByZWxlYXNlLCB3aXRoIGZ1cnRoZXIgZml4ZXMgaW4gdGhlIE9wZW5MREFQ IAo+Mi40LjQ2IHJlbGVhc2UuICBUaHVzIEkgd291bGQgYWR2aXNlIGEgZmlyc3Qgc3RlcCBvZiB1 cGdyYWRpbmcgdG8gT3BlbkxEQVAgCj4yLjQuNDYuCj4KPldhcm0gcmVnYXJkcywKPlF1YW5haAo+ Cj4KPi0tCj4KPlF1YW5haCBHaWJzb24tTW91bnQKPlByb2R1Y3QgQXJjaGl0ZWN0Cj5TeW1hcyBD b3Jwb3JhdGlvbgo+UGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0 aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQOgo+PGh0dHA6Ly93d3cuc3ltYXMuY29tPgo= ------=_Part_106754_1961220656.1537947199160 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGkgUXVhbmFoo6w8L2Rpdj48ZGl2PlRoYW5rcyBhIGxv dCBmb3IgeW91ciBoZWxwLiBJIHdpbGwgdXBncmFkZSBteSBvcGVubGRhcCB0byAyLjQuNDYgdmVy c2lvbiB0aGVuIGhhdmUgYSB0cnkuIHRoYW5rcyBhZ2Fpbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PmJlc3QgcmVnYXJkcyw8L2Rpdj48ZGl2Pm5hbmN5PGJyPjwvZGl2Pjxicj48YnI+PGJyPjxk aXYgc3R5bGU9InBvc2l0aW9uOnJlbGF0aXZlO3pvb206MSI+PC9kaXY+PGRpdiBpZD0iZGl2TmV0 ZWFzZU1haWxDYXJkIj48L2Rpdj5BdCAyMDE4LTA5LTI1IDA4OjU5OjIxLCAiUXVhbmFoIEdpYnNv bi1Nb3VudCIgJmx0O3F1YW5haEBzeW1hcy5jb20mZ3Q7IHdyb3RlOiZndDstLU9uIFR1ZXNkYXks IFNlcHRlbWJlciAyNSwgMjAxOCAxOjQ2IEFNICswMDAwIG5hbm1vckAxMjYuY29tIHdyb3RlOgo8 cHJlPiZndDsKJmd0OyZndDsgRnVsbF9OYW1lOiBOYW5jeSBNbwomZ3Q7Jmd0OyBWZXJzaW9uOiBv cGVubGRhcC1jbGllbnRzLTIuNC40NC0xNS5lbDdfNS54ODZfNjQKJmd0OyZndDsgT1M6IFJlZGhh dCA3CiZndDsmZ3Q7IFVSTDogZnRwOi8vZnRwLm9wZW5sZGFwLm9yZy9pbmNvbWluZy8KJmd0OyZn dDsgU3VibWlzc2lvbiBmcm9tOiAoTlVMTCkgKDEwNi4zOC4wLjg3KQomZ3Q7CiZndDtIZWxsbywK Jmd0OwomZ3Q7VGhlIElUUyBzeXN0ZW0gaXMgZm9yIGJ1ZyByZXBvcnRzIG9ubHkuICBQbGVhc2Ug ZGlyZWN0IHVzYWdlIHF1ZXN0aW9ucyB0byAKJmd0O3RoZSBvcGVubGRhcC10ZWNobmljYWwgbGlz dC4gIEkgd2lsbCBub3RlIHRoYXQgSSd2ZSB0ZXN0ZWQgT3BlbkxEQVAgMi40LjQ2IAomZ3Q7d2l0 aCBib3RoIHN0YXJ0VExTIGFuZCBMREFQUyB1c2luZyBUTFMgMS4zIHdoZW4gY29tcGlsZWQgb24g Ym90aCB0aGUgc2VydmVyIAomZ3Q7YW5kIGNsaWVudCBzaWRlIHdpdGggT3BlblNTTCAxLjEuMSBh bmQgaXQgd29ya2VkIGNvcnJlY3RseS4gIFlvdSB3aWxsIG5lZWQgCiZndDt0byBwcm92aWRlIHNp Z25pZmljYW50bHkgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB5b3VyIGNvbmZpZ3VyYXRpb24vc2V0 dXAgCiZndDt3aGVuIGNvbnRhY3RpbmcgdGhlIG9wZW5sZGFwLXRlY2huaWNhbCBsaXN0IGZvciBh bnkgZnVydGhlciBhc3Npc3RhbmNlLgomZ3Q7CiZndDtJIHdvdWxkIGFsc28gbm90ZSB0aGF0IG9m ZmljaWFsIHN1cHBvcnQgZm9yIE9wZW5TU0wgMS4xLjAgYW5kIGxhdGVyIHdhcyBub3QgCiZndDth ZGRlZCB1bnRpbCB0aGUgT3BlbkxEQVAgMi40LjQ1IHJlbGVhc2UsIHdpdGggZnVydGhlciBmaXhl cyBpbiB0aGUgT3BlbkxEQVAgCiZndDsyLjQuNDYgcmVsZWFzZS4gIFRodXMgSSB3b3VsZCBhZHZp c2UgYSBmaXJzdCBzdGVwIG9mIHVwZ3JhZGluZyB0byBPcGVuTERBUCAKJmd0OzIuNC40Ni4KJmd0 OwomZ3Q7V2FybSByZWdhcmRzLAomZ3Q7UXVhbmFoCiZndDsKJmd0OwomZ3Q7LS0KJmd0OwomZ3Q7 UXVhbmFoIEdpYnNvbi1Nb3VudAomZ3Q7UHJvZHVjdCBBcmNoaXRlY3QKJmd0O1N5bWFzIENvcnBv cmF0aW9uCiZndDtQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRp b25zIHBvd2VyZWQgYnkgT3BlbkxEQVA6CiZndDsmbHQ7aHR0cDovL3d3dy5zeW1hcy5jb20mZ3Q7 CjwvcHJlPjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxwPiZuYnNw OzwvcD48L3NwYW4+ ------=_Part_106754_1961220656.1537947199160--

1 0

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

24 Sep '18

--On Tuesday, September 25, 2018 2:06 AM +0000 hyc(a)symas.com wrote: >> Why the openldap client can not use TLS1.3? > > RedHat builds their OpenLDAP packages with MozillaNSS, not OpenSSL. Incorrect. Their latest builds for RHEL7 use OpenSSL. --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#8920) OpenLDAP
by hyc＠symas.com 24 Sep '18

24 Sep '18

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 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? RedHat builds their OpenLDAP packages with MozillaNSS, not OpenSSL. -- -- 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#8920) OpenLDAP
by quanah＠symas.com 24 Sep '18

24 Sep '18

--On Tuesday, September 25, 2018 1:46 AM +0000 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) Hello, The ITS system is for bug reports only. Please direct usage questions to the openldap-technical list. I will note that I've tested OpenLDAP 2.4.46 with both startTLS and LDAPS using TLS 1.3 when compiled on both the server and client side with OpenSSL 1.1.1 and it worked correctly. You will need to provide significantly more information about your configuration/setup when contacting the openldap-technical list for any further assistance. I would also note that official support for OpenSSL 1.1.0 and later was not added until the OpenLDAP 2.4.45 release, with further fixes in the OpenLDAP 2.4.46 release. Thus I would advise a first step of upgrading to OpenLDAP 2.4.46. 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

(ITS#8920) OpenLDAP
by nanmor＠126.com 24 Sep '18

24 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

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