Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!ucbvax!daemon From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: voting on the time Message-ID: <10027@ucbvax.ARPA> Date: Tue, 20-Aug-85 16:58:35 EDT Article-I.D.: ucbvax.10027 Posted: Tue Aug 20 16:58:35 1985 Date-Received: Fri, 23-Aug-85 08:36:59 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 18 From: David C. Plummer in disguiseDate: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. But what happens if somebody spazzes and warps MIT-MC 9 months into the future. (It has happened before.) What if one of the files you check against was created by such a time-warped machine? Indeed, the normal case will be caught by your probable-bogosity meter, but when the baseline is bogus, then what? What about systems who can't access the filesystem until the time is known?