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;
pgp9c6ETL2kea.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
