Re: Please review: OpenLDAP support

[Howard Chu]

>  Message: 1
>  Date: Mon, 06 Jul 2009 13:20:22 -0600
>  From: Rich Megginson<rmeggins(a)redhat.com> 
>  Note - the patch does not contain the diffs for configure nor
> Makefile.in
>  http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch 
We probably should talk about exposing the UTF8 APIs. The only reason they 
were kept private is because they weren't part of the RFC1823 or the expired C 
API draft, but they've been present for at least the past 9 years.

re: ldif_read_record() and the public LDIF API, note our ITS#5892; some of the 
function signatures here will change soon so that error can be distinguished 
from EOF. (But since 2.4's APIs are supposed to be frozen it may wait until 2.5.)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Please review: OpenLDAP support

[Rich Megginson]

Howard Chu wrote:
> > Message: 1
> > Date: Mon, 06 Jul 2009 13:20:22 -0600
> > From: Rich Megginson<rmeggins(a)redhat.com>
>
> > Note - the patch does not contain the diffs for configure nor 
> > Makefile.in
> > http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch
>
>  We probably should talk about exposing the UTF8 APIs. The only reason 
>  they were kept private is because they weren't part of the RFC1823 or 
>  the expired C API draft, but they've been present for at least the 
>  past 9 years. 
Yeah, the utf8 API is in kind of a weird place.  Some stuff is
provided 
by the OS, like utf8 <-> charset conversion (iconv), some stuff is 
provided by third party libraries we already use (ICU).  It's really odd 
that an LDAP library should provide a utf8 API - it just seems as though 
there should be a more widespread utf8 API library (ICU is very 
heavyweight if that's all you're going to use it for -  a sledgehammer 
for a thumbtack).  However, since utf8 is so integral to LDAP, having 
LDAP expose a useful API would be a good thing.
>  re: ldif_read_record() and the public LDIF API, note our ITS#5892; 
>  some of the function signatures here will change soon so that error 
>  can be distinguished from EOF. (But since 2.4's APIs are supposed to 
>  be frozen it may wait until 2.5.) 
Ok.  We will have to track that and be prepared
when the change occurs.  
Thanks for the heads-up.

Please review: OpenLDAP support

[Howard Chu]

Howard Chu wrote:
> > Message: 1
> > Date: Mon, 06 Jul 2009 13:20:22 -0600
> > From: Rich Megginson<rmeggins(a)redhat.com>
>
> > Note - the patch does not contain the diffs for configure nor Makefile.in
> > http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch 
As noted in your patch, the OpenLDAP API doesn't provide any options to 
control SSL session caching. In the past I hacked that into my clients by 
retrieving the OpenSSL context handles and using the OpenSSL API directly. 
Obviously that's not a viable way forward since we now have 3 different TLS 
libraries to deal with. So, we will probably be adding a couple set_option() 
flags for this purpose Real Soon Now. If there's anything good or bad about 
the way MozLDAP handles this, let me know what you think...

We'll also be providing a callback for obtaining the password for the private 
key... Again that's something we've ignored because OpenSSL has provided its 
own for so long.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Please review: OpenLDAP support

[Rich Megginson]

Howard Chu wrote:
>  Howard Chu wrote:
> >
> >> Message: 1
> >> Date: Mon, 06 Jul 2009 13:20:22 -0600
> >> From: Rich Megginson<rmeggins(a)redhat.com>
> >
> >> Note - the patch does not contain the diffs for configure nor 
> >> Makefile.in
> >> http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch
>
>  As noted in your patch, the OpenLDAP API doesn't provide any options 
>  to control SSL session caching. In the past I hacked that into my 
>  clients by retrieving the OpenSSL context handles and using the 
>  OpenSSL API directly. Obviously that's not a viable way forward since 
>  we now have 3 different TLS libraries to deal with. So, we will 
>  probably be adding a couple set_option() flags for this purpose Real 
>  Soon Now. If there's anything good or bad about the way MozLDAP 
>  handles this, let me know what you think... 
Actually, the way we do it is bad,
which is to disable caching on 
outgoing SSL connections.  Nelson commented on this in a thread on 
mozilla.dev.tech.crypto.  I think you use SSL_SetSockPeerID() but I'd 
have to look up that thread to be sure.
>  We'll also be providing a callback for obtaining the password for the 
>  private key... Again that's something we've ignored because OpenSSL 
>  has provided its own for so long. 
This is tricky - with MozNSS you have to do this
before you detach from 
the terminal, but after you fork().

Please review: OpenLDAP support

[Rob Crittenden]

Howard Chu wrote:
>  Howard Chu wrote:
> >
> >> Message: 1
> >> Date: Mon, 06 Jul 2009 13:20:22 -0600
> >> From: Rich Megginson<rmeggins(a)redhat.com>
> >
> >> Note - the patch does not contain the diffs for configure nor 
> >> Makefile.in
> >> http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch
>  
>  As noted in your patch, the OpenLDAP API doesn't provide any options to 
>  control SSL session caching. In the past I hacked that into my clients 
>  by retrieving the OpenSSL context handles and using the OpenSSL API 
>  directly. Obviously that's not a viable way forward since we now have 3 
>  different TLS libraries to deal with. So, we will probably be adding a 
>  couple set_option() flags for this purpose Real Soon Now. If there's 
>  anything good or bad about the way MozLDAP handles this, let me know 
>  what you think...
>  
>  We'll also be providing a callback for obtaining the password for the 
>  private key... Again that's something we've ignored because OpenSSL has 
>  provided its own for so long.
>   
libcurl has a similar SSL abstraction layer that works with OpenSSL, 
GnuTLS and NSS. You might find some inspiration there.

rob