• issue992 - feature request for short secure version identifiers


  • short, secure, fast
  • identify pristine state (id guarantees we hve same pristine)
  • identify patch set (guarantee we have same patch set)
  • accepts patch reordering
  • rejects false patch contents (patch info for A but something else in contents)
  • rejects false ordering even of true patch contents (clever and malicious)

Notes and questions

Is rejecting false ordering problem really just a natural consequence of identifying pristine? What was the example used? You manually reorder the patches so that if you later commute the patches you end up launching the missiles?

Scenarios and use cases

Fetching a repository by identifier (Zooko)

Alice has a repository. She generates an identifier. It less than 40 characters long. She sends it to Bob. Bob has read-access to a different repo, owned by Charles. He then tells darcs "Using Charles’s repo, get the version identified by this identifier. Darcs then (very very quickly) does one of two things: tells him it can’t because Charles’s repo doesn’t have all the patches that it would need, or does so, resulting in a local repo (on Bob’s computer) which has exactly the set of patches in it that Alice intended when she generated the identifier.

The “secure” part simply means that if darcs does the second case (fetches the patches) instead of the first case (says that it can’t), then Bob doesn’t have to consider Charles as part of the equation of what set of patches that he got. Bob knows that he got the set of patches Alice intended, regardless of Charles’s intention. (Charles could of course force darcs into the “I can’t do that” branch, for example by deleting his repository or turning off his network connection.)


id pristine id-patchs et commute-frie ndly spots-fake-pat ches spots-fake-ord ering
context hash no yes no NO! no
naive inventory hash yes yes NO yes yes
minimal context hash yes yes yes yes yes
pristine hash yes NO yes no no