On Sat, 20 Jul 2019 at 13:00, Michael Ströder michael@stroeder.com wrote:
On 7/20/19 10:51 AM, Nikos Voutsinas wrote:
On Sat, Jul 20, 2019 at 11:28 AM Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote: On 7/20/19 8:25 AM, Nikos Voutsinas wrote: > In the view of the new openldap release, I ran some tests by using
the
> current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree Which snapshot? Really the latest 407ce9d prepared for release andwith
latest mdb merge?Yeap the one tagged for 2.4.48
Ok.
> The testing environment was a Debian (Stable/Buster) and > Openldap was compiled with the Debian's gnu TLS libs. Could you try to link with OpenSSL and test that to preclude thatit's
an issue with GnuTLS?Whenever it was a gnutls library issue, even the plain ldapsearch -H ldaps:// had problems. Now this is not the case, cmd line utils from the same build at the same remote ldaps:/// work.
There are changes in libldap and slapd-ldap related to TLS which might not work correctly with GnuTLS.
So could you try to first link with OpenSSL? If that works it would mean that the GnuTLS support needs some more work.
Ok that can be done, although I am pretty sure that it will work with OpenSSL since you have already tested a similar setup on openSUSE.
The idea here is to first confirm with others the problem and then early identify the change set that triggers this before the announcement of the release
What worries me is that the exact config options and gnutls libs with the 2.4.47 source works as expected, thus we can not blame GNUTLS for that, despite any arguments one may have against GNUTLS.
BTW: During the last days Quanah and me investigated an issue with a (now reverted) patch for libldap only occuring with dhcpd using libldap. ldapsearch and many other LDAP clients were working just fine.
Ciao, Michael.