Re: commit-message attack for extracting sensitive data from rewritten Git history

From: Jeff King <peff@peff.net>
Date: Apr 9, 2013, 17:01 UTC
Message-ID: <20130409170159.GC21972@sigill.intra.peff.net>
In-Reply-To: <5163AF2C.2020107@viscovery.net>

On Tue, Apr 09, 2013 at 08:03:24AM +0200, Johannes Sixt wrote:

Show 16 quoted lines

> Am 4/8/2013 23:54, schrieb Jeff King:
> > Yeah, it would make sense for filter-branch to have a "--map-commit-ids"
> > option or similar that does the update. At first I thought it might take
> > two passes, but I don't think it is necessary, as long as we traverse
> > the commits topologically (i.e., you cannot have mentioned X in a commit
> > that is an ancestor of X, so you do not have to worry about mapping it
> > until after it has been processed).
> 
> Topological traversal is not sufficient. Consider this history:
> 
>      o--A--o--
>     /     /
>  --o--B--o
> 
> If A mentions B (think of cherry-pick -x), then you must ensure that the
> branch containing B was traversed first.

Yeah, you're right. Multiple passes are necessary to get it completely right. And because each pass may change more commit id's, you have to recurse to pick up those changes, and keep going until you have a pass with no changes.

But I haven't thought that hard about it. There might be a clever optimization where you can prune out parts of the history (e.g., if you know that all changes to consider are in descendants of a commit, you do not have to care about rewriting the commit or its ancestors).

-Peff