living in a multi-mech world

[Tom Yu]

>>>>> "Sam" == Sam Hartman <hartmans at MIT.EDU> writes:

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> On Mon, Apr 30, 2007 at 12:16:44AM -0500, Nicolas
Nicolas> Williams wrote:
>>> Pseudo-mechs shouldn't get direct access to other mechs -- they
>>> should always re-enter the mechglue (recursion ends because the
>>> various input parameters refer to other mechanisms -- as long
>>> as the pseudo-mechanism itself is not infinitely recursive).
>>> 
>>> Re-entering the mechglue from pseudo-mechanisms should add some
>>> overhead (extra frames on the stack), but not data copies.

Nicolas> Although, provided
Nicolas> gss_get/set_name/cred/context_mech_specific() functions
Nicolas> and a gss_dlopen() then it would be reasonable for
Nicolas> pseudo-mechs to invoke the mechanisms directly.  And that
Nicolas> would save a bit of overhead.
Nicolas> _______________________________________________ krbdev
Nicolas> mailing list krbdev at mit.edu
Nicolas> https://mailman.mit.edu/mailman/listinfo/krbdev

Sam> I think your first statement was more correct.
Sam> While you might make bypassing the mechglue work, it seems like it adds a lot of complexity.

I think it's reasonable for someone to want to have a SPNEGO mechanism
support only the krb5 mech, for example, so the SPNEGO mech could load
the krb5 mech and dlsym() the GSS-API entry points.

---Tom