Re: conflicting gssapi libraries
Gabor Gombas <gombasg@sztaki.hu> writes:
> GSSAPI was created to allow the use of multiple authentication
> mechanisms. If you do not want to allow that, then you should just get
> rid of GSSAPI completely and use the Kerberos APIs directly, as in this
> case GSSAPI just adds a lot of unneccessary complexity.
All of the GSSAPI libraries under discussion, MIT and Heimdal included,
implement an indirection layer and allow other mechanisms to be plugged
in. The only unique part about the UMich library is that it offers
nothing other than a mechglue layer, whereas the other implementations
provide both a mechglue layer and some specific mechanism implementations.
> Apart from the library naming issue, the UMich library is doing the
> Right Thing wrt. the original intentions of the GSSAPI. Applications
> should just depend on the _interface_.
Except that they can't just depend on a generic mechglue layer provided by
all possible implementations because the different GSSAPI implementations
offer slightly different symbols in areas not covered by the standard but
which applications actually use.
> The actual implementation selection should be a system-local policy and
> should not be hard-coded in dependencies.
I think you're confusing pluggable GSSAPI *mechanisms*, which everyone
agrees is a good idea, with pluggable GSSAPI *mechglue*, which is harder
and which doesn't offer clear benefits for Debian (at least in my
opinion). It feels like one level of indirection too many to me.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: