[Date Prev][Date Next]
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:
Patch related to "(ITS#6110) GSSAPI signing/encryption for
unsuspectingly applications" is more an enhancement than a bug
That's fine, patches are supposed to be tracked in ITS anyway.
However, it seems to me that these patches are duplicating
that's already provided by SASL/GSSAPI. On that basis I'm inclined
reject them. I'm beginning to regret including the
function as well; that is totally nonstandard and duplicates
functionality that has been available in the standard API for over 8
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,
SASL offers wide variety of authentication mechanisms. The
that ldap_gssapi_bind doesn't require any special configuration and
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
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