[darcs-users] down with timestamps! (was: patch file naming)
zooko at zooko.com
Sat Mar 20 13:12:56 UTC 2004
> Since synchronization of serial numbers between different computers is
> impossible, I'm not sure what they would gain us.
I didn't mean for the serial numbers to be synchronized across different
computers. I meant to reduce the risk that programmers will see the timestamps
and write code comparing timestamps that were generated on different computers.
If you use instead sequence numbers, each of which starts at 0 on its own
computer and increments by one whenever it generates a patch on its own
computer, then programmers will not mistakenly think that they are comparable
across different sources.
> > (b) the monotonicity of the clock on a single computer is not robust even
> > in the non-adversarial case, and is even less robust in the adversarial
> > case.
> If someone has the capability of resetting your clock, I think the danger
> of them tricking you into recording a second patch with the same name as
> one you previously recorded is the least of your worries.
Actually, there are cases where an attacker can mess with your clock
but can't mess with anything more powerful. (One arises because clocks are
often adjusted to match remote clocks, which can give the attacker a chance to
influence the clock. Another is that clocks are not considered to be security
sensitive by users, making them more easily tampered with by social
Also, the local clock will be non-monotonic even in the absence of malice.
(This has actually happened to me, even though nobody was maliciously trying to
interfere with my computer, and it took me a long time to track down the source
of the resulting bugs.)
Consider this argument: all clocks run too fast or too slow, compared to some
other, more precise clock. (Some clocks may run too fast sometimes and too
slow other times.) In order to make your local clock match a remote clock as
closely as possible (e.g through ntp), you will have to either (a) ensure that
your local clock *never* runs too fast, and instead *always* runs too slow, or
(b) occasionally set your clock back in time in order to be closer to the
Therefore, your local clock cannot simultaneously guarantee monotonicity and a
close approximation to a remote clock.
In practice Unix (with ntp) tries to make the local clock match a remote clock,
so it will occasionally automatically roll back the clock a tiny amount.
The problem gets worse when you look at others kind of disruptions. Users can
reset their clocks, perhaps in order to more closely match another clock that
is important to them. My MacOS X laptop has twice reset its clock to 1980 (or
some such year) since I bought it last fall.
If you can't tell, this is a detail which I feel strongly about. I dislike the
sloppy Unix tradition of "well, it is monotonic most of the time, so we'll
assume that it is monotonic, and just ignore or work around the occasional case
that this assumption isn't true". I don't like that attitude for normal
engineering, and I especially don't like it for security-sensitive engineering.
More information about the darcs-users