[15826] in Kerberos_V5_Development
Re: Sanity check: GSSAPI SPI simplifications
daemon@ATHENA.MIT.EDU (Luke Howard)
Mon May 24 19:16:49 2010
Mime-Version: 1.0 (Apple Message framework v1078)
From: Luke Howard <lukeh@padl.com>
In-Reply-To: <CD1CF89724AA83857D6EBABF@minbar.fac.cs.cmu.edu>
Date: Tue, 25 May 2010 01:15:22 +0200
Message-Id: <074EAC3E-884A-46FA-B75A-6683308FF6D2@padl.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Cc: krbdev@mit.edu, Nicolas Williams <nicolas.williams@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 25/05/2010, at 12:49 AM, Jeffrey Hutzelman wrote:
> --On Friday, April 30, 2010 03:52:44 PM -0500 Nicolas Williams
> <Nicolas.Williams@oracle.com> wrote:
>
>>> 1. The mechglue implements gss_acquire_cred in terms of gss_add_cred,
>>> and gss_add_cred in terms of mech->gss_acquire_cred. It never invokes
>>> mech->gss_add_cred.
>>>
>>> As a consequence, there is about 300 lines of orphaned code in the
>>> krb5 mech. I propose to get rid of it, and to eliminate gss_add_cred
>>> from struct gss_config. (Similarly for gss_add_cred_impersonate_name,
>>> which is already nulled out in the krb5 mech.)
>>
>> I've noticed this before. Please do eliminate this dead code.
>
> So, this would make the krb5 mech no longer be a GSS-API implementation.
> I suppose that's OK, if you assume that your mech is only ever going to be
> used with your mechglue. The problem is that as soon as more than one
> implementor makes that assumption, you stop being able to use arbitrary
> sets of mechanisms -- you can only use sets of mechanisms for which there
> is a mechglue with which they are all compatible.
This is a good point.
-- Luke
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
