This means an attacker can record each message and replay it at any time.

It is not clear to me from the documentation whether or not any possible message contains some unique information that will never be repeated in any later messages.

If this is the case, feel free to close this ticket but please clarify the documentation accordingly.

Otherwise, I would strongly suggest to add some sort of transaction counter to the hash from which the nonce will be created.

A simple incrementing counter should suffice, as the hash function will totally garble the bits anyway.

However, even then the question arises when the counter is initialized and where it is stored.

For that reason, it might be better if the server created a "session string" at the beginning of each sync session and sends it to the client.

This string could consist, for instance, of the current date and time plus a small random number in order to thwart scripted replay attacks which might exploit a low clock resolution of the server.

This session string is then augmented by an integer counter that starts at 0 at the beginning of each session.

Using this or a similar scheme will guarantee that each combination of session string and message counter will always be unique, and an attacker has no chance of launching a replay attack.

drh added on 2009-11-04 12:36:40:
A fossil repository is an unordered set of artifacts. The "unordered" part is important - the artifacts can arrive at the repository in any order without changing the meaning of the repository at all. A further consequence of this is that the same artifact can be sent into the repository multiple times without changing the repository. Hence, a replay is utterly harmless.