Re: multi-mechanism gssapi

[Luke Howard <lukeh@padl.com>]

Hi Johan,

>Yes, we should fix this, but I'm afraid that my time is very limited
>right now. I don't know what Love is up to.
>
>Just to let you know we're listening. :-)

What if we were to:

(a) move SPNEGO and Kerberos GSS-API mechanisms in Heimdal into
    libmech_spnego and libmech_krb5 libraries, respectively
(b) have each library export a gss_mechanism dispatch table
(c) use the CITI libgssapi to implement the exposed GSS API

For binary compatability, libgssapi would link in the Kerberos/SPNEGO
mechanisms (also because we have programs that use mechanism-specific
API such as gss_krb5_ccache_name()). But others, on platforms that
support it, could be dynamically loaded by exporting a gss_mechanism
table. (I prefer this approach to looking for each GSS function as
it allows applications to use mechanism-specific API by linking against
the mechanism library directly. The only problem is versioning,
particularly as we would want to support API extensions such as
gss_wrap_ex().)

Before I start down this track (or a related one), I'd like to know the
likelihood of it being integrated into Heimdal. I'm prepared to write
from scratch if you would prefer. :-)

(FWIW the CITI code originates from Sun and is under a BSD license
without the advertising clause.)

Also, there is the Sun TI-RPC mechglue library around somewhere, which
apparently is the Solaris 8 code, but I can't seem to find it anywhere
and it is released under a different license.

-- Luke

--