Re: SHA1 collision in production repo?! (probably not)

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2017, 17:35 UTC
Message-ID: <xmqqh929z6wl.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <4D74C1D4-9EA7-4A17-AFC5-0B54B4A6DD0E@gmail.com>

Lars Schneider <larsxschneider@gmail.com> writes:

Show 15 quoted lines

> Hi,
>
> I just got a report with the following output after a "git fetch" operation
> using Git 2.11.0.windows.3 [1]:
>
> remote: Counting objects: 5922, done.
> remote: Compressing objects: 100% (14/14), done.
> error: inflate: data stream error (unknown compression method)
> error: unable to unpack 6acd8f279a8b20311665f41134579b7380970446 header
> fatal: SHA1 COLLISION FOUND WITH 6acd8f279a8b20311665f41134579b7380970446 !
> fatal: index-pack failed
>
> I would be really surprised if we discovered a SHA1 collision in a production
> repo. My guess is that this is somehow triggered by a network issue (see data
> stream error). Any tips how to debug this?

Perhaps the first thing to do is to tweak the messages in builtin/index-pack.c to help you identify which one of identical 5 messages is firing.

My guess would be that the code saw an object that came over the wire, hashed it to learn that its object name is 6acd8f279a8b20311665f41134579b7380970446, noticed that it locally already has the object with the same name, and tried to make sure they have identical contents (otherwise, what came over the wire is a successful second preimage attack). But your loose object on disk you already had was corrupt and didn't inflate correctly when builtin/index-pack.c::compare_objects() or check_collision() tried to. The code saw no data, or truncated data, or whatever---something different from what the other data that hashed down to 6acd8..., and reported a collision when there is no collision.