[darcs-devel] [issue772] bug in get_extra commuting patch

David Roundy bugs at darcs.net
Mon Mar 31 20:29:24 UTC 2008



On Mon, Mar 31, 2008 at 01:32:43PM -0600, zooko wrote:
> On Mar 31, 2008, at 9:38 AM, David Roundy wrote:
> >This is a duplicate of issue27.  It's debatable whether this is a bug in
> >darcs or a bug in tailor.  Zooko would argue, I'm sure, that darcs
> >shouldn't give you the power to shoot yourself in the foot.
> 
> My argument is that patch ids should be unique, so that it is  
> impossible for there to exist two different patches with the same  
> patch id.  This is a property that monotone guaranteed, which git  
> adopted, and which mercurial and bzr now offer as well.
>
> It seems like it could be a useful property to rely upon.  It could
> theoretically be used by a future version of darcs to cryptographically
> verify the provenance of a repository, the way that monotone and the
> others already do.

You can never rely upon this property in the presence of hostile attackers,
and in the absence of hostile attackers, the existing behavior is
adequate.  I would say that if one developer creates two patches with the
same name at the same time, he's most likely hostile or he's using a
poorly-designed tool.  If one developer creates patches using another
developer's name then he's definitely hostile (or perhaps confused as to
his identity).

> The "garbage" that David referred to in his note would be a secure hash
> of the contents of the patch and the context of the patch, just as is
> done in the other revision control tools.

No, it would be a secure hash of the contents of the patch and its context
*at the time that it's created*, which is something that cannot be verified
or used in any way (except perhaps if you're lucky, or don't use much of
darcs' functionality).  So assuming it's a secure hash, then this is
garbage.

The key mistake you're making is that you seem to assume that we could
check this hash, but it's an uncheckable hash, because there's no reason to
believe we could ever again recreate that context.  So this information is
no more useful than a truly random number.  Its only advantage over a few
bytes from /dev/random would be (a) that it doesn't deplete your entropy
pool and (b) that tools like tailor would generate the same output when run
twice on the same repository.

> Hopefully it wouldn't need to be encoded into the long patch  
> description itself, however, since that could collide with other uses  
> of the long patch description.  Hopefully the patch hash information  
> could be stored with the patch description in a separate field, just  
> like monotone and the others do.

Sorry, it *would* be encoded into the long patch description itself.  As
I've explained to you before.  I'm not going to break
backwards-compatibility.
-- 
David Roundy
Department of Physics
Oregon State University

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue772>
__________________________________


More information about the darcs-devel mailing list