[darcs-users] [issue992] short secure version identifiers

[Nathaniel W Filardo]

On Tue, Jun 23, 2009 at 12:26:38PM -0600, Zooko Wilcox-O'Hearn wrote:
> On Jun 23, 2009, at 12:23 PM, Nathaniel W Filardo wrote:
>
>> It's not clear to me why you want to capture the "filesystem state"  
>> anyway,
>> since the "filesystem state" is always encoded entirely in the patch
>> configuration, which is exactly what the context (and inventory) files
>> describe.  It is, for example, always safe to "rm -rf
>> _darcs/pristine.hashed/*; darcs w" -- darcs will rebuild the pristine 
>> trees
>> (it'll take a bit of time to do it, but otherwise the behavior is
>> identical).
>
> If there were a secure mapping from patch ID or patch hash to the effect 
> that a patch has, then what you wrote above would suffice.
>
> But currently, an attacker could substitute a different patch body with 
> the same patch ID/patch hash, right?

Ah ha, you've found one of darcs' dirty little secrets.  Darcs, when trading
patches, doesn't use hashes as identifiers.  Part of this is because it's
rewriting patches in the case of conflicts (AFAIR).  IMHO, both of these are
bugs rather than features but I haven't pushed through a stably named
variant on patch theory (what I've sometimes called a theory with "local
superceders").  When generating patches' representations on disk, on the
other hand, darcs uses its charmingly unique 10-digit-length+SHA256 hash
function.  It should be impossible to replace the patch on disk.

You might be able to sneak a patch in by some bundle, pull, or push, since
darcs is relatively trusting that a patches, in core, are equivalent up to
(date,author,comment) -- that is, content collapses out.

--nwf;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090629/3b617244/attachment.pgp>