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
