|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
MIME-Version: 1.0 From: Jeffrey Hutzelman <jhutz@cmu.edu> Date: Tue, 25 May 2010 10:46:56 -0400 To: Luke Howard <lukeh@padl.com> Message-ID: <e07913f3-b161-4c0a-8e1a-f2974c6dec77@email.android.com> 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 Sure, but that doesn't help if the hypothetical SCRAM mech in question comes from someone who assumed it would never be used outside of _their_ mechglue, which uses a different subset of the GSS-API. "Luke Howard" <lukeh@padl.com> wrote: >> 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
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |