[darcs-users] down with timestamps! (was: patch file naming)

David Roundy droundy at abridgegame.org
Sat Mar 20 14:15:03 UTC 2004

On Sat, Mar 20, 2004 at 08:12:56AM -0500, Zooko O'Whielacronx wrote:
> > 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.

But then you will need to add some random number into the mix in order to
avoid duplicate patch IDs.  But mostly, it's not my business to try to keep
other programmers making mistakes.  Besides that, it's a bit hard for me to
see what a programmer could do with timestamps from darcs patches that
could cause a problem (that is, without creating code that will essentially
never work).

The timestamp information *is* useful to humans, and therefore should be
included.  It is very nice to be able to do things like correlate emails
with patches (e.g. did I create this patch after I got a certain email, or
before?), or to find a patch that you remember you recorded just before
Christmas vacation.  It's not just about a human-readable unique number,
it's also just helpful information.

> > > (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 engineering.)

True, but setting your clock so that you will accidentally record a second
patch with the same name as a previous one at precisely the same time would
be an interesting challenge, and in practice would probably require
completely stopping your clock, which is the sort of thing that would be
pretty easy to notice.

> 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.)
> 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.

Fortunately, since this amount is less than a second, monoticity *can* be
guaranteed on the level of darcs timestamps (at least provided you have
decent kernel support on your operating system).  ntp is designed precisely
to provide a monotonic clock that synchronizes with a remote time server by
adjusting the *speed* of your clock rather than adjusting its time (which
is why it'll just give up if the clock is wrong by more than a few

> 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.

Darcs doesn't care whether it's monotonic, as long as it's unique.
Admittedly, if it's not monotonic you can run into uniqueness issues, but
that's a problem that exists even in the absence of monotonicity problems.
David Roundy

More information about the darcs-users mailing list