[2499] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Porting problems in V5

daemon@ATHENA.MIT.EDU (Tony Lill)
Thu Jan 7 11:45:23 1993

To: athena.mit.edu!kerberos@eddie.mit.edu
In-Reply-To: Your message of "15 Dec 92 22:08:44 GMT."
Date: Mon, 04 Jan 93 10:04:04 -0500
From: Tony Lill <harvard!scubed!riipsdev.waterloo.ncr.com!ajlill@eddie.mit.edu>

>> In article <9212082146.AA07100@riipsdev.waterloo.ncr.com> harvard!scubed!riipsdev.waterloo.ncr.com!ajlill@eddie.mit.edu writes:
>> >For those of you lucky enough not to have dealt extensively with DOS don't
>> >know, the DOS time() call returns the number of seconds since midnight, Dec
>> >31, 1899, rather than Jan 1, 1970.
>> 
>> That's strange.  Every DOS C compiler I've used returns seconds since
>> Jan. 1, 1970.  The only time I've seen something based on 1899/1900
>> was in code that queried a time server for the time.  time()'s very
>> definition depends on the Unix epoch of 1/1/70.

Surprise! In C 7.0, they changed the definition of time. 

>> No matter what, you have the right solution, I think.  A better solution,
>> if possible, would be to fix the offset used by your time() call.

Yes, after trying to make Kerberos work with this weird definition of
time, I've found that for the decrypt integrity checks (as written) to
work depends on both machines using the same epoch to encode time 0,
so I'll be changing krb5_timestamp to offset it. I've already provided
my own gmtime since the one in the Windows 3.1 SDK libraries is sooooo
broken, it's not funny (they don't even have a large model object in
the large model library!).

Windows/NT the death of UNIX? At least UNIX knows what time it is!

>> >Pepsy (from isode 8.0) turns that into an int when it creates it's
>> >tables.
>> 
>> That's a bug in Pepsy-on-DOS, or Pepsy-on-PDP-11 for that matter.  :-)
>> Someone did a port of ISODE to DOS a while back.  You might see if you
>> can find that port, since the Pepsy there probably has this bug fixed.

Actually, that problem turned out to be a bug in int2prim() or
something not getting what was expected in 0x1ff<<24. (Hint: this is 0
on a 16 bit machine).

- ---
Tony Lill,                                 Tony.Lill@Waterloo.NCR.COM
President, A. J. Lill Consultants                 (519) 650 0660
539 Grand Valley Dr., Cambridge, Ont.             (519) 653 9732
presently at E&M Waterloo, NCR Canada Ltd.        (519) 884 1710 x624
					     voice plus 643 1624

"Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"

home help back first fref pref prev next nref lref last post