krb5 thread support and excess support libraries -- seekingopinions, options

Nicolas Williams Nicolas.Williams at
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 
> ignore.
> 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 
> >>N
> >>platforms.
> >
> >If using shared libs, every platform I have seen only needs the gss 
> >lib,
> >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 mailing list