Re: What about SHA-1 collisions?

From: Shawn Pearce <spearce@spearce.org>
Date: Nov 7, 2012, 15:42 UTC
Message-ID: <CAJo=hJtF2+Z1BDQnysB7hk2MM336iEUMHd3zSLCm14yvw1_-wg@mail.gmail.com>
In-Reply-To: <20121106220938.GH28437@raven.wolf.lan>

On Tue, Nov 6, 2012 at 2:09 PM, Josef Wolf <jw@raven.inka.de> wrote:

Show 20 quoted lines

>
> On Tue, Nov 06, 2012 at 09:41:29PM +0000, John McKown wrote:
> > Josef Wolf <jw <at> raven.inka.de> writes:
> > > Just for curiosity: what would happen if such a collision would occur within
> > > one repository?
>
> > In a sense, this cannot happen.
>
> In the scenario you described, contents of this version of file "b" are lost
> and replaced by the contents of file "a". So file "b" is broken.
>
> What happens when files "a" and "b" are added into different repositories?
> File "a" is added to repos "A", and file "b" is added to repos "B". Now it
> depends from which repository you fetch the collided blob first. If you fetch
> it from "A", file "b" will be broken. If you fetch first from "B", your "a"
> will be broken.
>
> It becomes even more interesting, if some commit or tree object would have
> the same SHA1 as some other object. I guess, in such a case the repository
> would be completely hosed?

When exchanging objects over the network, Git compares byte-for-byte any object that one side sent that the other side already has, and complains loudly when there is a collision detected. This only works if the sender includes the "wrong" content for the named object. Git also does assume the SHA-1 is unique and that it is not always necessary to transmit the object. In these cases you would not be able to detect the collision, because there isn't one. Your repository would simply be using the wrong content for a file. Presumably one would notice your build doesn't work anymore and investigate why.