Re: removing content from git history

From: Nicolas Pitre <nico@cam.org>
Date: Feb 21, 2007, 18:39 UTC
Message-ID: <alpine.LRH.0.82.0702211321040.31945@xanadu.home>
In-Reply-To: <Pine.LNX.4.64.0702211009520.4043@woody.linux-foundation.org>

On Wed, 21 Feb 2007, Linus Torvalds wrote:

Show 8 quoted lines

> 
> 
> On Wed, 21 Feb 2007, Nicolas Pitre wrote:
> So supermodules might be a way to solve it in a better (and safer - the 
> "remove objects from the public tree" thing is very error prone, since if 
> you *ever* expose the object by mistake, its now public) way. But I don't 
> think the "filter out objects" thing is necessarily fundamentally flawed 
> as an approach.

Well if you really wanted to do such a thing then you could use a new object type that only serves as a stub pretending to be another object which SHA1 would have been xyz. When referenced this object would generate a warning indicating to the user that given object has been excised out, but otherwise the whole reachability validation would still work as usual.

And since this object would be distributed through standard mechanisms then there would be no need for protocol extensions.

I don't know if this could help creating SHA1 collisions though. We've dismissed them as highly improbable because the likelihood of a collision to hide compromised material would most probably require a binary blob somewhere to balance the hash and would hardly be compilable/undetected. But with object stubs with the ability to pretend having any possible SHA1 is in fact a nice way to hide 20-byte binary blobs in the hash chain possibly making it "easier" to create "useful" collisions. This is where I see a weakening of the trust model.

Nicolas