krb5 thread support and excess support libraries -- seekingopinions, options
Nicolas.Williams at sun.com
Thu May 6 15:49:41 EDT 2004
On Thu, May 06, 2004 at 03:31:46PM -0400, Ken Raeburn wrote:
> On May 6, 2004, at 09:59, Douglas E. Engert wrote:
> >But we now have the IETF KCRYPTO draft, which was meant to allow for
> >the user of the K5 crypto without the rest of Kerberos. So can the
> >k5crypto be setup to support this?
> It can be, yes. It could still be done even if the k5crypto and krb5
> libraries were merged; there'd just be a lot more exported symbols to
> Actually, you may not be able to use the k5crypto code without the krb5
> library. Some of the crypto functions take a krb5_context parameter,
> and while sometimes it's not used, I don't think we're generally
> asserting that it can be NULL. I don't recall if there are cases where
> NULL will actually break things right now, but if we start doing stuff
> like caching key schedules and derived keys, the krb5_context would be
> one obvious place to store the cache. So I think it's safe to say that
> even if you don't use the krb5 protocol, just the crypto functionality,
> you still need the krb5 library.
Aside: in our discussions with Sam about derived key caching we
discussed having a new krb5_keyblock with the keys cached therein, with
a new magic value and constructors/destructors for krb5_keyblock that do
the right thing. The krb5_context is not really a good place to stored
derived keys anymore than it is a good place to put extended
get_init_creds prompts. But there could be other things you might want
to cache in a context structure of some sort...
> >>For that matter, we should be able to link apps and libraries against
> >>just the libraries they use directly -- e.g., link against
> >>libgssapi_krb5 only, if it doesn't do any Kerberos stuff directly, and
> >>have the dependencies recorded in the library pull in the other needed
> >>libraries, preferably without messing with the symbol namespace,
> >>either. But I don't think I've got time to investigate that soon for
> >If using shared libs, every platform I have seen only needs the gss
> >and it will force the rest of the libs to be loaded.
> (1) Does the application see the krb5 symbol names in that case?
This should depend on how the gss mech is linked. I don't know about
other linkers, but on Solaris you can link the gss mech so that symbols
from its dependencies do not pollute the caller's namespace.
More information about the krbdev