Article View: comp.protocols.kerberos
Article #920Re: Porting problems in V5
From: Tony Lill
Date: Mon, 04 Jan 1993 15:04
Date: Mon, 04 Jan 1993 15:04
44 lines
2827 bytes
2827 bytes
>> 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!"
Technical Details
Message-ID:
<9301041504.AA03631@riipsdev.waterloo.ncr.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!gatech!udel!wupost!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!stanford.edu!EDDIE.MIT.EDU!harvard!scubed!riipsdev.waterloo.ncr.com!ajlillReferences:
<1gll1cINNs0o@usenet.INS.CWRU.Edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.protocols.kerberos Path: arc1-ca.pugleaf.net!sparky!uunet!gatech!udel!wupost!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!stanford.edu!EDDIE.MIT.EDU!harvard!scubed!riipsdev.waterloo.ncr.com!ajlill From: harvard!scubed!riipsdev.waterloo.ncr.com!ajlill@EDDIE.MIT.EDU (Tony Lill) Subject: Re: Porting problems in V5 Message-ID: <9301041504.AA03631@riipsdev.waterloo.ncr.com> Sender: news@shelby.stanford.edu (USENET News System) Organization: Internet-USENET Gateway at Stanford University References: <1gll1cINNs0o@usenet.INS.CWRU.Edu> Date: Mon, 4 Jan 1993 15:04:04 GMT Lines: 44