Re: Commit SHA1 == SHA1 checksum?

From: Gamblin, Todd <gamblin2@llnl.gov>
Date: Feb 6, 2022, 09:00 UTC
Message-ID: <188C988E-F679-4AD6-AA04-E51F11F7D9A7@llnl.gov>
In-Reply-To: <121ce485-bea8-3168-aa35-d11eb13022da@iee.email>

Thanks for the quick response.

> I don't think there is an obvious cross-check for the tarball sha1
> comparison with the release tag's sha1, if that's the question.

This is pretty much the question — does git do an integrity check on clone to verify that the commit hash (and its tree hash) are valid?  Does git verify objects as they’re written to disk when it’s cloning a repo?

> The tag contains the sha1 hash of the release commit, which in turn
> contains the sha1 hashes of the tree that is being released, and the 
> previous commit in the git history, and onward the hashes roll...

It seems like git fsck is supposed to check all of these, so would that be the potential analog? It seems like overkill if all I really want is the integrity of one commit snapshot.  Would it be sufficient to heck the hash of the checked out commit and then to check its tree hash… I guess I’m just curious why git doesn’t have a command that verifies the integrity of the current working tree against its commit sha1.

> /git/YA3nwFcYz4tbhrlO@camp.crustytoothpaste.net/ in the thread notes
> "The signature is .. over the uncompressed .tar ... You therefore need
> to uncompress it first with gunzip.”

This is a good point and would make it hard to tar up a repo into any verifiable single file for download, given only a commit sha1 for verification — gunzipping without the tarballs’ checksum is unsafe. I guess I would like to know if I can even verify the integrity of a checked out git repo by commit sha1 before I try to do a tarball or anything more complex.

Thanks again, Todd

Show 44 quoted lines

> On Feb 5, 2022, at 4:22 PM, Philip Oakley <philipoakley@iee.email> wrote:
> 
> On 05/02/2022 01:19, Gamblin, Todd wrote:
>> Apologies if this has been asked before, but the closest thing I could find was this thread:
>> 
>> 	https://urldefense.us/v3/__http://public-inbox.org/git/Pine.LNX.4.62.0504160519330.21837@qynat.qvtvafvgr.pbz/__;!!G2kpM7uM-TzIFchu!k7dRSHz8ms3qNYldu2HO6BZzvN91qqtPk7UXsmQzw3hgIQN33-9EdfLtzjN9XzGM1Q$ 
>> 
>> That thread devolved into a discussion of the security of different hashes and didn’t answer my question.
>> 
>> I want to know when and where git *guarantees* that the snapshot I have checked out has the checksum that git says it does, or if it does at all.
>> 
>> The use case for this is for package managers. I work on Spack (https://urldefense.us/v3/__http://github.com/spack/spack__;!!G2kpM7uM-TzIFchu!k7dRSHz8ms3qNYldu2HO6BZzvN91qqtPk7UXsmQzw3hgIQN33-9EdfLtzjPp-H3Ccg$  if you’re curious) and we download sources from tarballs and git repos (like many similar tools).  For tarballs we require a sha256, and we use it to verify the tarball after download.
>> 
>> For git repos, we would like to require a commit sha1, provided that it’s basically as secure as downloading a tarball and checking it against a known sha1.  So, if I `git clone` something, is the commit sha1 actually verified?
> For the Git releases, the maintainer, Junio, will PGP sign the release
> tag with his key e.g.
> https://urldefense.us/v3/__https://git.kernel.org/pub/scm/git/git.git/tag/?h=v2.35.1__;!!G2kpM7uM-TzIFchu!k7dRSHz8ms3qNYldu2HO6BZzvN91qqtPk7UXsmQzw3hgIQN33-9EdfLtzjNaNI59hw$ 
> 
> The tag contains the sha1 hash of the release commit, which in turn
> contains the sha1 hashes of the tree that is being released, and the 
> previous commit in the git history, and onward the hashes roll...
> 
> https://urldefense.us/v3/__https://lore.kernel.org/git/xmqqh7n5zv2b.fsf@gitster.c.googlers.com/__;!!G2kpM7uM-TzIFchu!k7dRSHz8ms3qNYldu2HO6BZzvN91qqtPk7UXsmQzw3hgIQN33-9EdfLtzjOPuUZJdQ$  is
> a recent discussion on the refreshing of the PGP key. the post
> https://urldefense.us/v3/__https://lore.kernel.org__;!!G2kpM7uM-TzIFchu!k7dRSHz8ms3qNYldu2HO6BZzvN91qqtPk7UXsmQzw3hgIQN33-9EdfLtzjPlWc_eSQ$ 
> 
> /git/YA3nwFcYz4tbhrlO@camp.crustytoothpaste.net/ in the thread notes
> "The signature is .. over the uncompressed .tar ... You therefore need
> to uncompress it first with gunzip."
>> 
>> Thanks,
>> -Todd
>> 
>> 
>> PS: I know that sha1 has been declared “risky” by NIST and that folks should move away from it, and please be assured that we’re using sha256’s everywhere else.  Here I really just want to know whether cloning a git repo at a particular commit is as secure as downloading a tarball and checking it against a sha1, not whether or not sha1 is secure.
>> 
>> 
> I don't think there is an obvious cross-check for the tarball sha1
> comparison with the release tag's sha1, if that's the question.
> 
> The repeatability of tarballs has been discussed but I didn't find a
> mail reference immediately.
> 
> Philip