Re: conflicting gssapi libraries
Brian May <firstname.lastname@example.org> writes:
>>>>>> "Russ" == Russ Allbery <email@example.com> writes:
> Russ> It may be that they were trying to provide an indirection
> Russ> layer between MIT and Heimdal so that people could choose
> Russ> whichever they want at runtime. I'm not sure of another
> Russ> reason for it. The UMich library doesn't actually implement
> Russ> GSSAPI at all; it requires that another implementation (MIT
> Russ> or Heimdal) be available and just calls into the other
> Russ> library.
> GSSAPI isn't limited to just Kerberos, you could implement other
> protocols in GSSAPI too.
Yes; the MIT library, for example, implements both a krb5 mechanism and an
SPNEGO mechanism, and the Heimdal library implements krb5, SPNEGO, and
> Having said that, the only GSSAPI libraries in Debian I know of are
> the two Kerberos libraries.
No one inside of Debian or out, so far as I know, ships separate mechanism
implementations for existing mechglue layers. One reason why not is
probably that the maintainers of existing mechglue layers have been happy
to include all mechanisms with those layers.
Here, here's a table that summarizes my understanding of the situation and
Library Mechglue? Mechanisms
--------------- --------- ------------------------------
Heimdal yes Kerberos, SPNEGO, NTLM
MIT yes Kerberos, SPNEGO
UMich libgssapi yes -none- 
libgss yes Kerberos 
 Requires that some other GSSAPI library be installed and calls into
the mechglue layer of *that* library to provide all of its
 Uses Shishi for its Kerberos implementation, which is wire-compatible
with other Kerberos implementations but not, so far as I know, fully
compatible with ticket caches, configuration, and similar local
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>