[krbdev.mit.edu #2914] size change in cache breaks alpha-dux40 for krb5-1.3, krb5-1.4

[Ken Raeburn via RT]

On Feb 4, 2005, at 18:19, Quanah Gibson-Mount via RT wrote:
>> I can't reproduce this on krb5-1.2.4 and krb5-1.3.5 on an Alpha which
>> I have access to.
>
> Tom,
>
> Is it 4.0f?

We have 5.1a, which is why the 4.0 stuff is completely untested.
Well, our having 5.1a, plus no feedback on the beta versions.  Hint, 
hint. :-)

> Here's the krb5-1.2.8 od -tax1 output:
>
> tru64-build:~> od -tax1 /tmp/tkt54046
> 0000160   X   |   r   %   X stx  fs   .   | dc3  cr   j   G  ht   C sub
>         d8 7c 72 25 d8 82 9c ae fc 93 0d ea c7 09 43 1a
> 0000200   P   _   x del   o   c   f syn   g   }  si   i   } etx   B
>         d0 df f8 ff ef 63 e6 96 67 fd 8f 69 fd 03 42
> 0000217

In the 1.2.7 sources I have lying around, and a 1.2.8 tree I just 
checked out, the last thing written to the file by tf_save_cred in 
lib/krb4/tf_util.c is one of the arguments declared "long issue_date", 
and written using sizeof(long).  So I'm surprised that last field looks 
like a four-byte timestamp.

> Here is the krb5-1.3.6 od -tax1 output:
> 0000200   P   9   /   H   :   y   w dc1   w   `   d stx soh eot   B nul
>         50 b9 2f c8 ba f9 f7 11 77 e0 64 02 01 04 42 00
> 0000220 nul nul nul
>         00 00 00
> 0000223

This is more like what I'd expect... 4 bytes of "normal" timestamp 
(with a value 921 seconds after the 1.2.8 example) plus 4 bytes of zero 
to make the full "long" value.

You don't have any local patches to 1.2.8 that might influence this?  
(Maybe trying to make 1.2.8 compatible with some previous version we 
accidentally broke compatibility with?)

Ken