[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: FW: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s

Hash: SHA1


We are trying to make likewise-open packages available for Fedora
but they only want to pull OpenLDAP patches from upstream.  So
I'm in a bit of a spot here.  You've already accepted the lsap_bind_gssapi
patch, this one simply exposes the existing code.

Is it just the public ldap_bind_gssapi_s() signature that you
have an issue with?  If, as you suggest, we give you a patch
that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep
the same (existing) ldap_bind_gssapi_s() internals, would that
be acceptable?

cheers, jerry
- -- 
Director of Engineering                      http://www.likewise.com/
Likewise-CIFS                            http://www.likewiseopen.org/
"What man is a man who does not make the world better?"      --Balian

On 6/2/10 12:10 AM, Scott Salley wrote:
> -----Original Message-----
> From: Howard Chu [mailto:hyc@symas.com]
> Sent: Tue 6/1/2010 6:07 PM
> To: Scott Salley
> Cc: openldap-its@openldap.org
> Subject: Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
> ssalley@likewise.com wrote:
>> Full_Name: Scott Salley
>> Version: HEAD
>> OS: Linux
>> URL:
> http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch
>> Submission from: (NULL) (
>> Note that a similar issue/contribution was submitted in 2008
> (Contrib/5369) and
>> appears to have been 'lost'.
>> The patch
> http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-define-have-gssapi.patch
>> makes it possible to use the GSSAPI support in OpenLDAP by:
>> 1. Defining --with-gssapi in configure which
>>   a. Checks for appropriate header files
>>   b. Checks for the appropriate library
>>   c. Defines HAVE_GSSAPI to 1 in everything is in order
>> 2. Exposing ldap_gssapi_bind_s in ldap.h
> I am still disinclined to publish any of this. The standard mechanism for
> using GSSAPI in LDAP is via SASL. I see no benefit to propagating more
> non-standard one-off ldap_XXX_bind flavors. It's a poor design approach
> and it
> increases our support workload for no appreciable gain. It increases
> application developer's workload as well, if they have to test for the
> existence of multiple flavors of ldap_XXX_bind and code for them each
> separately in their apps.
> If you really want to have "direct" access to other authentication
> mechanisms,
> the right way to do this is by adding new LDAP_AUTH_xxx definitions that can
> be muxed out from a single ldap_bind API. Of course, by the time you've
> implemented option parsing so that generic client code can be configured
> with
> arbitrary Bind mechanisms, you would have re-implemented SASL.
> --
>    -- Howard Chu
>    CTO, Symas Corp.           http://www.symas.com
>    Director, Highland Sun     http://highlandsun.com/hyc/
>    Chief Architect, OpenLDAP  http://www.openldap.org/project/

Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/