-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Howard,
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-defin...
Submission from: (NULL) (67.51.54.234)
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-defin...
makes it possible to use the GSSAPI support in OpenLDAP by:
- 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
- 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/
-
gcarterï¼ likewise.com