[1664] in Kerberos-V5-bugs
Re: beta-5.75 krshd compiled with v4 compatibility isn't from Linux to AIX
daemon@ATHENA.MIT.EDU (Mark Eichin)
Thu Oct 12 11:43:34 1995
From: Mark Eichin <eichin@cygnus.com>
Date: Thu, 12 Oct 1995 11:42:37 -0400
To: hartmans@MIT.EDU
Cc: krb5-bugs@MIT.EDU
In-Reply-To: <199510120404.AAA15283@tertius.mit.edu> (message from Sam Hartman
on Thu, 12 Oct 1995 00:04:36 -0400)
> I still think this is a good idea, but I'm not convinced that
> creating an interdependency between libkrb.a and libkrb5.a is a good
> idea. The shared library cruft in the build process is already bad
Right now we have a one-way dependency (in the MIT code): compat_recv
(sendauth compatibility) in libkrb5 requires things from libkrb4. In
the Cygnus tree, we've also got a dependency from libkrb4 to
util/profile (in order to find krb.conf/krb.realms/v4srvtab in a
controllable way) but except for aklog, any program that uses libkrb4
already has the profile code pulled in by other things in libkrb5, so
I wasn't concerned about that. I was expecting to put this code in the
MIT tree unless we figured out how to do the srvtab conversion.
One fix to consider is to put compat_recv et.al. *in* libkrb4, so that
libkrb4 *always* precedes libkrb5.
I'm surprised and concerned about the libkrb4 sendauth problem you
mention, it's probably some subtle interaction (as libkrb4 is based on
working CNS V4 code.) A send_to_kdc error is somewhat strange in that
context...
You mention aklog -- I've got a customer actually running aklog (and
worse, cklog) with libkrb4/libdes425/libcrypto (as well as an asetkey
that uses a v5 srvtab.) They are having no problems (anymore -- using
code that predates the keytype/enctype changes, the interrealm
krbtgt's need to have v4 salttype, but the code basically worked.)
> functional enough to eleviate any dependence on the old krb4 source
Anything that doesn't work with libkrb4 from the v5 tree is evidence
of a bug (somewhere.)
