On Thu, Oct 29, 2015 at 6:50 PM, Warren Young <[email protected]> wrote: > > But, I think you’re not realizing that artifact chaining removes the > attraction of replacing old artifacts. As I understand it, you can’t > replace an artifact 10 checkins back from the tip of the branch without > recomputing the 9 other hashes on the way back to the tip. Therefore, an > attack that takes a year of CPU time to attack a leaf node takes 10 years > to attack a node 10 checkins back from the tip. >
Supposed the work on "foo.c" is done. Subsequent commits will refer to most recent version of "foo.c". Replacing the contents of "foo.c" with "foo_evil.c", where H(foo.c) == H(foo_evil.c) now only requires creating a single "foo_evil.c". Depending on how long ago "foo.c" was last worked on, the devs might not notice the changes, especially if they don't diff it against the previous revision. Something my team does - though not for security reasons - is to archive the sources of a release to a separate archive, independent of the VCS repository. Then, when we make a new release, part of the process is to review all changes in the proposed new release against the source of the previous release. (This is in addition to the code reviews we do prior to integrating additions and fixes.) While not perfect, our release reviews increase the probability of detecting a "stealth" change before it gets released.
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
