krb5 thread support and excess support libraries -- seekingopinions, options
raeburn at MIT.EDU
Thu May 6 15:31:46 EDT 2004
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.
>> 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?
(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.
More information about the krbdev