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

Re: GSSAPI signing/encryption for unsuspectingly applications (its not a bug)


On Jul 2, 2009, at 2:49 AM, Howard Chu wrote:


Rafal Szczesniak wrote:

On Wed, May 13, 2009 at 03:06:57PM -0700, Howard Chu wrote:

mikbec wrote:

Patch related to "(ITS#6110) GSSAPI signing/encryption for
unsuspectingly applications" is more an enhancement than a bug report. 

That's fine, patches are supposed to be tracked in ITS anyway.
However, it seems to me that these patches are duplicating functionality that's already provided by SASL/GSSAPI. On that basis I'm inclined to reject them. I'm beginning to regret including the ldap_gssapi_bind_s() 
function as well; that is totally nonstandard and duplicates
functionality that has been available in the standard API for over 8
years.
ldap_gssapi_bind was never meant to replace or duplicate SASL part of the code. It's only an implementation that enables using GSSAPI directly, while Cyrus SASL offers wide variety of authentication mechanisms. The difference is that ldap_gssapi_bind doesn't require any special configuration and thus 
it's an easy way to have an interface for Active Directory.
This explanation makes no sense, since no *special* configuration is required to use SASL/GSSAPI with Active Directory. No matter what API you use, you must have Kerberos properly configured.
I would be concerned for having two APIs that do the same thing. This complicates clients.
I've long thought about implementing certain SASL mechanism natively, such as PLAIN and EXTERNAL, because at times I rather not deal with Cyrus SASL (or other SASL library alternatives). (I never did it because, well, because those times are rare.) BUT I think native implementations should present themselves with the same API.
If not, what happens is that client's end up having to have some configuration support (or other means) to select which implementation to use. 

-- Kurt