From: Junio C Hamano <gitster@pobox.com>
To: Kyle Lippincott <spectral@google.com>
Cc: Simon Josefsson <simon@josefsson.org>, Jeff King <peff@peff.net>,
git@vger.kernel.org
Subject: Re: Making bit-by-bit reproducible Git Bundles?
Date: Thu, 13 Mar 2025 15:09:17 -0700 [thread overview]
Message-ID: <xmqq5xkcmvle.fsf@gitster.g> (raw)
In-Reply-To: <CAO_smVgSRaYqNrA4c1yeu-cpj+P36MY+bsQT=8K0SXpWHkaWCQ@mail.gmail.com> (Kyle Lippincott's message of "Thu, 13 Mar 2025 14:07:16 -0700")
Kyle Lippincott <spectral@google.com> 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.
next prev parent reply other threads:[~2025-03-13 22:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 11:40 Making bit-by-bit reproducible Git Bundles? Simon Josefsson
2025-03-12 16:02 ` Junio C Hamano
2025-03-13 3:09 ` Kyle Lippincott
2025-03-13 7:59 ` Simon Josefsson
2025-03-13 5:15 ` Jeff King
2025-03-13 13:36 ` Junio C Hamano
2025-03-13 20:16 ` Simon Josefsson
2025-03-13 21:07 ` Kyle Lippincott
2025-03-13 22:09 ` Junio C Hamano [this message]
2025-03-14 2:42 ` Jeff King
2025-03-14 22:24 ` rsbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq5xkcmvle.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=simon@josefsson.org \
--cc=spectral@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).