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
(*) 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