[15834] in Kerberos_V5_Development
Re: Sanity check: GSSAPI SPI simplifications
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Tue May 25 11:30:12 2010
Date: Tue, 25 May 2010 10:29:50 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Message-ID: <20100525152949.GA9605@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <135b1249-7c83-452c-a624-0480c2bfcd2d@email.android.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, May 25, 2010 at 10:08:06AM -0400, Jeffrey Hutzelman wrote:
> "Nicolas Williams" <Nicolas.Williams@oracle.com> wrote:
> >Agreed. I *like* the API as the SPI, but not to the point where
> >mechanisms can be used directly without the mechglue. [...]
>
> OK; that's a fair point. But what about being able to combine mechs
> from multiple sources under one mechglue? What happenns when someone
> releases a SCRAM implementation and their own mechglue? If they make
> different assumptions, then neither mech works with the other
> provider's glue, and apps are stuck with the choice of supporting
> either krb5 or SCRAM (a decision the framework is supposed to save
> them from) but not both.
They shouldn't. Instead they should release mechanisms for existing
mechglues.
Just as no one bothers to use GSS mechs w/o mechglues, I doubt
developers will want to re-write mechglues every time they write mechs.
(Aside: I suspect that most mechglues will have sufficiently similar
SPIs that targeting multiple mechglues will generally be feasible.)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
