Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by krbdev.mit.edu (8.9.3p2) with ESMTP id SAA13810; Fri, 4 Feb 2005 18:55:46 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j14Ntj8v028465 for ; Fri, 4 Feb 2005 18:55:45 -0500 (EST) Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j14Nth0a005434 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 4 Feb 2005 18:55:44 -0500 (EST) MIME-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2f5634a98ba2a8ed44433aa945198c71@mit.edu> Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: [krbdev.mit.edu #2914] size change in cache breaks alpha-dux40 for krb5-1.3, krb5-1.4 Date: Fri, 4 Feb 2005 18:55:43 -0500 To: rt@krbdev.mit.edu X-Mailer: Apple Mail (2.619.2) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-BY: MIMEDefang 2.42 RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1572 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