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

[Ken Raeburn]

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.

>> 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?
(2) Yes, our installed libs can be used that way.  I'd like to be able 
to do such things in our build.  But it's a minor point.

Ken