>> I would have asked what other libgss could there possibly be. But >> then someone on the openssh mailing list pointed out that I should >> just bypass the libgssapi-0.7 stuff entirely
That was me - I cross posted my (somewhat lengthy) response here too, but it has yet to appear (I suspect that the address I sent it from may not be subscribed to this list). The short version of that post is that the CITI libgssapi currently breaks lots of things, and is best avoided. Thunderbird has now got checks in place to make sure it doesn't use it by mistake, and I suspect similar checks may be needed in any other program which dynamically loads their GSSAPI support, or uses a mechanism other than krb5-config to identify a suitable GSSAPI library. I'm not sure why OpenSSH got bitten by this - as, providing you've got a krb5-config file, OpenSSH will use that to identify which library to use. > Linking directly to libgssapi_krb5 is a hack and is generally not going > to be a portable solution. It's a fairly well established hack. The CITI libgssapi only just appeared in Linux, and doesn't appear to be in any of the BSDs (which have Heimdal's libgssapi) Also, until GSSAPI contains standard provision for saving delegated credentials, its exactly what you're going to need to do. Once OpenSSH has accepted a context, it needs to be able to save the credentials that have been passed through into a mechanism specific credential cache. In the Kerberos case, it does this by calling gss_krb5_copy_ccache() - which is provided by libgssapi_krb5. Perhaps, once the proposed extensions to GSSAPI are standardized, and implemented this will no longer be the case - but at the moment I can't see how you can have a mechanism independent glue library without sacrificing significant server side functionality. Cheers, Simon. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
