On Thu, Sep 11, 2014 at 10:18 AM, John Long <codeb...@inbox.lv> wrote: > On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote: >> On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams <n...@cryptonector.com> wrote: >> >> > > git branch -D name >> > >> > Eh, filesystems let you delete files. Unlike most filesystems, git lets >> > you restore your deleted branches (yes, provided you don't gc the repo). >> > >> >> Then just use a file system and various command line tools! But seriously, >> it's a philosophical difference between those who want to be able to >> rewrite their history to what they should have done and those who want to >> keep the history around to see what they did. > > I can understand for personal projects people might want stuff to disappear. > And I can understand vandals want to make stuff disappear when they attack a > system. But in a serious, large project there are often requirements for an > audit trail. There is no downside to this given the cheapness of backing > storage. And it can prevent all sorts of problems.
If you want a secure audit trail then you have to send the audit records elsewhere (preferably replicate the trails too). And you have to commit the audit records to their destinations before (or otherwise atomically as) commits are incorporated into a repo. Refusing to modify history doesn't make history unmodifiable -- Merkle hash chains alone only provide integrity protection for the past, but not if the attacker controls it and the present. An attacker can always edit the history directly via SQLite3 access to the repo. Of course, anyone who has fetched the pre-edit history will notice the re-write, which is why pushing and pulling often is helpful. Alternatively you can sign commits. Then editing history breaks the signatures, thus requiring re-signing of edited commits or a signature by some authority describing what history editing took place and why. > In the places I work the problem tracking system entries are immutable. And > [...] Nothing can really be made immutable, but you can detect mutation. That has nothing to do with whether a VCS permits mutation, and everything to do with using Merkle hash chaining and replicating (auditing, if you wish) the chains to secure storage as soon as possible so as to make mutation detectable. Whether to permit mutation for all, some, or no branches, is a policy decision to be made. I don't think one size fits all. Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
