- openldap-bugs - openldap.org

(ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 09 Oct '18

09 Oct '18

Full_Name: Nancy Mo Version: openldap-clients-2.4.46 OS: Redhat 7, ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.38.0.87) openldap Client: Ubuntu 16.04.4 LTS/ openldap 2.4.46/ openssl-1.1.1 openldap Server: redhat 7, Linux 3.10.0-327.13.1.el7.x86_64 #1 SMP Mon Feb 29 13:22:02 EST 2016 x86_64 x86_64 x86_64 GNU/Linux openldap2.4.46/ openssl-1.1.1 In Client, configure ldap.conf: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com URI ldap://mydomain.com:389 ldaps://mydomain.com:636 ssl start_tls TLS_CACERTDIR /usr/local/etc/openldap/cacerts TLS_CACERT /usr/local/etc/openldap/cacerts/cacert.pem TLS_REQCERT never #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never SASL_NOCANON on BASE cn=localhost debug 9 local4.* /var/log/ldap.log In server: configure the slapd.conf (some important configuration) database mdb maxsize 1073741824 suffix "dc=mydomain,dc=com" rootdn "cn=Manager,dc=mydomain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}srNLpYqpwEpRTw94IV79Myw5YO6rn0Ym # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/openldap.2.4.46/var/openldap-data TLSCACertificateFile /usr/local/openldap.2.4.46/etc/openldap/cacerts/cacert.pem TLSCertificateFile /usr/local/openldap.2.4.46/etc/openldap/ldap.crt TLSCertificateKeyFile /usr/local/openldap.2.4.46/etc/openldap/ldap.key >From client connect to server: ldapsearch -x -H ldaps://mydomain.com:636 -D cn=Manager,dc=mydomain,dc=com -w passw0rd -b "" -s base objectclass=* We can get the result, but from Wireshark result, we find that they used TLS1.2 to negotiated. The openSSL is support for TLS1.3,however openldap-2.4.46 is still used TLS1.2 by default. Need some parameters to specify TLS1.3 in openldap configuration? By the way, I have tested that other application can negotiated with TLS1.3 by default when the client and server both use openssl-1.1.1. Thanks a lot. Best regards, nancy Mo

1 0

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

05 Oct '18

On Tue, Sep 18, 2018 at 10:55:50PM -0700, Ryan Tandy wrote: >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. This turned out to be because the fd and timeout fields are only initialized when timeout is configured and the non-blocking behaviour was triggered because of it. Otherwise the code simply doesn't anticipate EAGAIN could be returned and the behaviour is more or less undefined; it ends up calling poll() with fd = -1 and a garbage timeout. >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.) More precisely, what I actually want is a (ret > 0) case that is used unless both USE_NON_BLOCKING_TLS is true and a timeout is configured. If we added to ber_sockbuf_ctrl() the ability to query whether the socket is non-blocking, for GnuTLS at least we could bypass poll() and go straight back into ldap_int_tls_connect(). However I don't see a lot of benefit to this as long as calling poll() on a blocking socket has no downside.

1 0

(ITS#8923) compare op with dynlist returns wrong code when requested DN is in scope but doesn't exist
by quanah＠openldap.org 03 Oct '18

03 Oct '18

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) In a situation where a dynamic group has been created and a compare operation is run with a DN that doesn't exist but is within the scope of the dynamic group URI, the ldapcompare operation will incorrectly return an error 80 instead of error 5 (compare FALSE). For example, if I have: dn: cn=planning,ou=Groups,dc=example,dc=com objectClass: groupOfURLs cn: planning memberURL: ldap:///ou=planning,dc=example,dc=com??sub?(objectClass=inetorgpers on) and I do an ldapcompare with: ldapcompare -x -H ldap://anvil2.rb.symas.net -D dc=example,dc=com -w secret cn=planning,ou=Groups,dc=example,dc=com "member:cn=Ramakant Wolow,ou=Planning,dc=example,dc=com" (i.e., this entry doesn't exist in the DB), I get: Compare Result: Other (e.g., implementation specific) error (80) UNDEFINED This appears to be due to the fact that in this scenario, slapd attempts to find the DN in the underlying DB and it doesn't exist, so an err=32 is returned back. This is incorrectly interpreted as an unknown error, thus the err=80 result. Instead it should be treated as "not a member of the group".

1 0

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 01 Oct '18

01 Oct '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 25 Sep '18

25 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 25 Sep '18

25 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 25 Sep '18

25 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 25 Sep '18

25 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#8919) common.c:2329: suspicious expression ?
by hyc＠symas.com 24 Sep '18

24 Sep '18

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) > > > common.c:2329:10: warning: logical not is only applied to the left hand side of > this bitwise operator [-Wlogical-not-parentheses] Next time please provide a full pathname, not just a filename. Next time please use "git diff" or "git format-patch" > 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. Next time read the code you're commenting on. This is an empty if statement, it has no effect regardless. -- -- 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#8919) common.c:2329: suspicious expression ?
by hyc＠symas.com 23 Sep '18

23 Sep '18

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) > > > 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. Please use diff. -- -- 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#8917) OpenLDAP
by quanah＠symas.com 23 Sep '18

23 Sep '18

--On Saturday, September 22, 2018 11:56 PM +0200 Matus Honek <mhonek(a)redhat.com> wrote: > 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. Hi Matus, I just happened to be looking into this yesterday (ITS#8914) and was able to successfully compile OpenLDAP with OpenSSL 1.1.1 without issue as well, and was able to confirm (via the TLS testsuite available in the OpenLDAP HEAD release) that TLS 1.3 works fine. I've followed up with the person who filed ITS#8914 to give more information on what issue(s) they faced since it works for me. 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 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs