Gabor Gombas <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]