Re: Commit SHA1 == SHA1 checksum?

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Feb 7, 2022, 13:15 UTC
Message-ID: <20220207131520.cqkdtmceddqquwlg@meerkat.local>
In-Reply-To: <734DE4FA-E4B1-43CB-89EE-3C200FA21F4F@llnl.gov>

On Mon, Feb 07, 2022 at 08:15:58AM +0000, Gamblin, Todd wrote:

> In our case, the initial trust doesn’t come from a PGP signature — it comes
> (at least for now) from having cloned the package repository from GitHub.

Not really the case, if you're relying on a particular commit hash, as you state. Once you specify a target hash, you don't really have to care where the repository came from -- the hash is either going to be there and be valid, or it's not going to be there.

It only matters where the person who picked that hash cloned the repository from and what steps they made to verify that it is a legitimate commit. If "I cloned this repository from github" is sufficient for your needs, then that's fine. The alternative is to use PGP verification, but in either case once you pick a hash to use, you can rely on git to do all the rest.

> That said, I guess I do still have one more question — how soon will git
> notice that a given repo is corrupted/tampered with (insofar as sha1 can do
> that)?  On checkout?

Yes. I've asked this question before as well: https://lore.kernel.org/git/20190829141010.GD1797@sigill.intra.peff.net/

The relevant bit:

    Then yes, there is no need to fsck. When the objects were received on
    the server side (by push) and then again when you got them from the
    server (by clone), their sha1s were recomputed from scratch, not
    trusting the sender at all in either case.

-K