apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Covener" <cove...@gmail.com>
Subject Re: [Patch] LDAP SSL support for Tivoli
Date Sat, 01 Dec 2007 17:40:35 GMT
On Dec 1, 2007 12:06 PM, Graham Leggett <minfrin@sharp.fm> wrote:
> Eric Covener wrote:
>
> > ldap_ssl_client_init() should be called once per process, not once per
> > connection.
>
> The LDAP SDK uses the ldap_set_option function for both once-per-process
> values (LDAP* is NULL) and once-per-connection values, and
> apr_ldap_set_option follows this pattern as well.
>
> Remember that one of the basic design goals of the APR LDAP code is to
> offer a consistent interface to 8 distinct APR LDAP clients, regardless
> of the underlying LDAP implementation, and this has been a mindbending
> task. Adding init code exclusively to apr_ldap_ssl_init() instead of
> apr_ldap_set_option() makes the Tivoli support work differently to the
> support maintained by other toolkits, and introduces inconsistent
> behaviour, which is exactly what the API is trying to avoid.

Upon return from apr_ldap_ssl_init(), SSL has not been initialised on
the underlying toolkit.  If the entire function, and not just the
setting of certificates is deprecated, we should make that more clear.

Additionally, it looks like if you "fail" to initialize SSL (native
return code indicating "already initialized" but maybe with different
SSL parameters)  in the per-connection context you're going to trigger
a failure in apr_ldap_init() which the program will see unnecessarily
and would have a difficult time coping with..

We can more elaborately trap native return codes, and try to ignore
some of the OPT_TLS failures, but it makes more sense to me to bake-in
the knowledge of when an SDK ought to call these functions at all.

> It cannot be assumed that other toolkits may be able to be further
> configured after the first LDAP connection is established.

the crux of the problem here is that setting the OPT_TLS_CERT and
creating the connection are two disjoint operations in APR, whereas to
be the most portable you'd want to have the complete set of
information available all at once (or have somewhere opaque to stash
away the cert info to use on the subsequent init() call)

-- 
Eric Covener
covener@gmail.com

Mime
View raw message