[5243] in Kerberos
Re: Cred cache b5/V3 format
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue May 23 20:20:06 1995
Date: Tue, 23 May 1995 20:13:54 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Joe Kovara <joek@CyberSAFE.COM>
Cc: kerberos@MIT.EDU
In-Reply-To: Joe Kovara's message of Tue, 23 May 1995 14:27:45 -0700,
<Pine.SUN.3.91.950523140637.18836A-100000@kerby.ocsg.com>
Date: Tue, 23 May 1995 14:27:45 -0700
From: Joe Kovara <joek@CyberSAFE.COM>
Beta 5 introduced a new cred cache format (V3). It appears that two
changes were made: the e-type in the key block; and an "architecture
independent" data format. I understand the reason for putting the e-type
in the key block. I also understand that architecture independence is
generally a Good Thing.
However, I'm curious as to what the designers had in mind for the
"architecture independent" cred cache. This change presents a significant
new interface to K5, and hence a new source of potential interoperability
problems.
Can someone please explain the genesis, requirements and goals of this
change? I think this would be of benefit to all providers and users of
K5.
Well, the moment we needed to go to a new credentials cache format (V3)
to add the e-type, I decided we might as well make the data format
architecture independent anyway.
Normally, credential caches are not designed to be moved across
machines, so it should not be considered a "new interface". I did it
basically because it was a "good thing". It also makes regression
testing of the library simpler, since we can put a fixed credentials
cache in the test suite and make sure that the credentials cache code
can read it properly. I also get very nervous when there is code which
outputs data formats which rely on "size of". Relying on "size of" some
type to remain constant across different versions of compilers,
operating systems, etc., isn't always a safe thing to do. (Example:
what happens when SGI migrates over to 64-bit in Irix V6? You might
have 32-bit and 64-bit applications which are simultaneously running at
the same time, both trying to access the credentials cache.)
I can think of a few cases where I might ask someone to uuencode to me
their credentials cache (after making sure the tickets had expired!).
For example, I did that once when I was trying to debug the DCE ASN.1
incompatibilities ---- but it took a lot of extra work to use that
credentials cache since it was created on HPUX system, and that had a
byte order which was backwards from the machine I was using at the time.
But in general, we did it because it was a "good thing to do".
- Ted
