Subject: Re: Making bit-by-bit reproducible Git Bundles?

From: Junio C Hamano <[email-masked]>
Date: Thu, 13 Mar 2025 15:09:17 -0700

Kyle Lippincott <[email-masked]> writes:

>> > But that implies you trust Git's object hash algorithm.
>>
>> Right -- I think anything but bit-by-bit identical files is going to be
>> too complex to verify.
>
> I'm curious what specific attacks you're trying to catch here. Because
> to get into a situation where you unbundle the bundle and have the
> same commit hash but different contents, you would need to have a
> collision in the SHA-1 hash for some object (or SHA-256 hash if the
> repo is using that). If you're also providing the instructions (or
> even just the commit hash and server to clone from, and linking to
> instructions maintained elsewhere) to validate the bundle is
> legitimate, it seems MUCH easier to just replace those validation
> instructions to point to a commit/server that has already been
> backdoored than it would be to generate a SHA-1 collision that would
> go undetected.

I think there are two levels of "verify" involved in this discussion.

There are those who want to trust bundles and and place enough trust
on whoever created that bundle.  They are happy as long as the
bitstream they received the first time does not change when they ask
for it for the second time, because they at least know that the same
input would result in the same output.  To them, "attack" is what
changes the bitstream while they are looking the other way.  They do
not like the fact that there can be more than one representations of
the same thing for this reason.

Then there are those who know Git enough to know that they do not
need to trust the middleman who create bundle files, and they do not
need to trust exact bitstream that is contained within these bundle
files.  They can extract the bundle to verify the tip commits of the
history (by comparing their object names with published hashes, by
verifying the embedded signatures, etc.), which is what ensures
integrity in Merkle tree based systems like history stored in Git.

The latter folks may worry about the "attacks" you mention here, but
the former may not necessarily do so.