-----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:[email protected]] > Sent: Tue 6/1/2010 6:07 PM > To: Scott Salley > Cc: [email protected] > Subject: Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s > > [email protected] 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) (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-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/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu 9/F8j8UQJ5C3X0sW5LytRq8= =tkYo -----END PGP SIGNATURE-----
