On Sat, Jul 20, 2019 at 4:46 PM Michael Ströder <mich...@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
