Deprecated ldap_int_tls_config in rlm_ldap

Arran Cudbard-Bell a.cudbardb at freeradius.org
Tue May 7 22:07:31 CEST 2013


On 7 May 2013, at 15:01, John Dennis <jdennis at redhat.com> wrote:

> On 05/07/2013 02:45 PM, Arran Cudbard-Bell wrote:
>>> But more to the point OpenLDAP has addressed the TLS configuration
>>> issues a while ago.
>> 
>> Do you know the version? Want to make sure that it's checked in the
>> autoconf script.
> 
> I don't think you need to check this in autoconf, you're not looking for the presence of a function, the correct methodology is to use the existing interfaces that have always been there, but pass new constants. In the patch you'll see the code is ifdef'ed so it only compiles if the constant is in the header file. If the constant is in the header but the library still doesn't understand it (not likely) you should get an error back which will be logged.

Fair enough.

> 
> P.S. I'm not sure if you were thinking about falling back to the old methodology if you don't find the new mechanism. Don't do that. If the new mechanism isn't there for some reason the best approach IMHO would be to issue a warning, but don't try to use an internal non-public API instead. BTW the "_int_" in the symbol name ldap_int_tls_config stands for internal.

Yes I know, it was wrong.

Ok i've pushed back a modified version of your patch. I disliked the fact that it did the string to enum conversion when it created a connection as it means -C wouldn't of caught an invalid value for tls.require_cert. The conversion is now done when the module is instantiated.

I've also removed the default value so that it'll use whatever libldap uses as a default. This is so we can warn appropriately if setting cert requirements is not supported.

and apparently it's 'Fixes #<issue>' which makes more sense. Stupid google.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team



More information about the Freeradius-Devel mailing list