[1663] in Kerberos-V5-bugs
Re: beta-5.75 krshd compiled with v4 compatibility isn't from Linux to AIX
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Oct 12 00:04:51 1995
Date: Thu, 12 Oct 1995 00:04:36 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, eichin@cygnus.com
In-Reply-To: "[1653] in Kerberos-V5-bugs"
>>>>> "hartmans" == Sam Hartman <hartmans@MIT.EDU> writes:
hartmans> The current build of krshd in the krb5 locker, build
hartmans> from a snapshot taken September 8 for AIX fails when the
hartmans> Linux-Athena krsh (V4) tries to connect to it with a
hartmans> decrypt integrity error. I don't
It would have helped had I had /etc/srvtab and /etc/krb.conf
in place. With those user-error fixes, it works.
Mark Eichin asked me to include a feature request with this
followup to my bug report for the following behavior:
* the krb4 libs distributed with krb5 should, ideally, use a v5srvtab
and v5configuration files to get their configuration info and keys.
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
enough, and I don't want to think about dealing with how run-time
resolution works on supported platforms (especially AIX, but I suspect
we'll run into problems on at least one other platform). It's
something to think about.
In closing, I do have an actual bug: the sendauth in our
libkrb (v4) is broken. I compiled telnet with KRB4 defined, and was
unable to authenticate to portnoy, a Sun in the SIPB office. Portnoy
does not require encryption, so the v5 client should be able to
connect. I believe I got a send_to_kdc error--checksum integrity
error if memory serves correctly. Tonight, I built v5 telnet using v5
libcrypto, /usr/athena/lib/libkrb.a and libdes425.a out of the current
source tree. This works fine; someone should debug the client code in
libkrb.a. Honestly, we should probably try building clients like
Zephyr andaklog with this library; it would be nice if it was
functional enough to eleviate any dependence on the old krb4 source
tree.
--Sam
