Thanks for testing. I will file the pullup request right now. We don't have any local changes for openldap so this looks like an upstream break and fix.
Best, christos > On Aug 9, 2019, at 7:57 PM, Brad Spencer <[email protected]> wrote: > > [email protected] (Christos Zoulas) writes: > >> In article <[email protected]>, >> Brad Spencer <[email protected]> wrote: >>> >>> I compiled up 9.0_BETA and upgraded a 8.x DOMU. I found that 9.0_BETA >>> suffers from the bug I wrote about in lib/53675. Basically, ldaps won't >>> work. In particular, it appears that the client code is broken as >>> ldapsearch will refuse to work against an openldap server and against a >>> 389DS server if you try using SSL/TLS (ldaps). I had a slightly older >>> -current around with libcrypto.so.13 on it and it works fine, but >>> anything with libcrypto.so.14 does not work, although the problem could >>> be in the libldap library. The upgraded DOMU did not have its packages >>> updated, so those were still from the 8.x era. A ldapsearch from pkgsrc >>> of the 8.x era also worked, but it uses an older libcrypto and its own >>> libldap. >>> >>> I won't have much time to fiddle with this problem any more right now, >>> but can offer up test systems if anyone would like to help fix this. >>> >>> Right now, -current and 9.0_BETA are probably broken with respect to >>> client use of ldaps from the base system (this includes pam_ldap and >>> nss_ldap). >> >> I just imported the latest one on HEAD. Please let me know if it fixes >> your problem. >> >> Thanks, >> >> christos > > > Thanks Christos... I was able to test a build of -current with the > newer imported OpenLDAP and it appears to work just fine. There was no > problems with ldapsearch and ldaps and even the older packages worked > which suggest no API breakage. I would request that this import be > pulled into 9.0 if possible. > > > -- > Brad Spencer - [email protected] - KC8VKS - http://anduin.eldar.org
