On Sat, Jul 20, 2019 at 4:46 PM Michael Ströder michael@stroeder.com wrote:
On 7/20/19 3:41 PM, Michael Ströder wrote:
On 7/20/19 1:31 PM, Nikos Voutsinas wrote:
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.
Let's not speculate about whatever might be the cause or not.
Just start testing. Take care not to mess up builds and test results (like I did sometimes during the last days).
BTW: Are your 2.4.47 and 2.4.48 builds are done exactly the same way?
OPENLDAP_REL_ENG_2_4_48 with OpenSSL-1.1.1c (on Debian / Buster) works OPENLDAP_REL_ENG_2_4_48 with GNUTLS-3.6.7 (on Debian / Buster) doesn't work(*) OPENLDAP_REL_END_2_4_48 also works on Solaris with openssl
OPENLDAP 2.4.47 Debian's official package with GNUTLS-3.6.7 also works
(*) I also tried to pass the trusted CAs via olcTLSCACertificateFile in cn=config after Ondřej's comment, with the same result.
In any case the heads up on the devel list was mostly to identify a possible issue at the openldap side before the release. If it turns out to be a Debian specific issue, then I assume that the Debian's Openldap Maintainers will take of it.
Nikos