[15832] in Kerberos_V5_Development
Re: Sanity check: GSSAPI SPI simplifications
daemon@ATHENA.MIT.EDU (Luke Howard)
Tue May 25 10:27:30 2010
Mime-Version: 1.0 (Apple Message framework v1078)
From: Luke Howard <lukeh@padl.com>
In-Reply-To: <135b1249-7c83-452c-a624-0480c2bfcd2d@email.android.com>
Date: Tue, 25 May 2010 16:27:14 +0200
Message-Id: <4D243964-407A-4564-9AB5-2AA5DEC0F5C9@padl.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Cc: "krbdev@mit.edu" <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
> 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.
Recall also that the MIT mechglue supports dynamic loading of shared objects that themselves export the GSS API.
-- Luke
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
