On Mon, Mar 5, 2012 at 18:49, Richard Hipp <d...@sqlite.org> wrote: > On Mon, Mar 5, 2012 at 6:34 PM, Leo Razoumov <slonik...@gmail.com> wrote: >> >> What happens if an attacker can shun artifacts, rebuild database, edit >> commit messages, events, tickets, etc? >> Fossil sync might happily pull compromised items into a local repo. >> Carefully crafted commit edits might disguise malicious actions. >> Am I being paranoid:-)? > > When you pull in the revised content, the shuns done on the server will not > typically be pulled over. So when you run a timeline on your local repo > (using "fossil ui") you'll see two completely separate lines of development > - the legacy clean line and the bogus line inserted by the attacker. Surely > this will clue in that something is wrong. > > I guess the attacker could add artifacts that move the check-in times for > the clean legacy checkins back in time to (say) 1970, where you are unlikely > to notice them. But even then, when you go to do your next commit, the > commit will still attach to your legacy line of development, assuming you > haven't done a "fossil update BRANCH" to some BRANCH that the attacker has > redefined.
I typically do "fossil update trunk". So, I guess, in this case I am hosed. > > > But even if you don't discover the attach right away, the immutable audit > trail is still there in the repository. So you can go back and see what > happened. This is good feature of fossil. Full chain of custody and a forensic trail. > Be careful not to let the attacker trick you into pulling over the shunning > list though. If the attacker can shun, then they can do a lot of virtually > undetectable damage. > "auto-shun" is enabled by default in any newly created fossil repo. Is it a wise default choice? --Leo-- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
