<div dir="ltr"><div dir="ltr"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 1:45 PM Steve Langasek <<a href="mailto:vorlon@debian.org">vorlon@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 09, 2020 at 01:07:11PM -0600, Matt Zagrabelny wrote:<br>
> Unfortunately FreeRADIUS is linked against openssl and cannot properly use<br>
> Debian's libldap-2.4-2, which is linked against gnutls, for TLS<br>
> communication.<br>
<br>
Independent of questions of whether openldap should switch to openssl, could<br>
you elaborate why FreeRADIUS being linked against openssl causes a problem<br>
for a module linked against gnutls?  The two implementations should be<br>
entirely independent and able to operate independently within the same<br>
process.<br></blockquote><div><br></div><div>I agree. It should work. Why it doesn't...<br></div><div><br></div><div>Short answer. I don't know.</div><div><br></div><div>Medium answer: Upstream states that gnutls claims to be compatible with openssl, but it isn't compatible. If you search the net for "Alan DeKok openssl gnutls ldap" you'll get hits.<br></div><div><br></div><div>Long guessing answer: Perhaps the FR LDAP module (rlm_ldap) makes library calls that it expects to behave a certain way. If gnutls is providing those function endpoints, it might be failing because the module (rlm_ldap) is using openssl specific semantics.</div><div><br></div><div>I can confirm empirically that FR using libldap* works when openldap is built with openssl and fails when libldap* uses gnutls. It fails at the TLS layer - that is, the TLS connection fails.</div><div><br></div><div>I would wager that upstream has no interest in modifying its code to work with gnutls (or Mozilla NSS).<br></div><div><br></div><div>-m<br></div></div></div>