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

[Nicolas Williams]

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.

Nico
--