- 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)
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?
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|
|naive inventory hash||yes||yes||NO||yes||yes|
|minimal context hash||yes||yes||yes||yes||yes|