git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Gamblin, Todd" <gamblin2@llnl.gov>
To: Philip Oakley <philipoakley@iee.email>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Commit SHA1 == SHA1 checksum?
Date: Sun, 6 Feb 2022 09:00:42 +0000	[thread overview]
Message-ID: <188C988E-F679-4AD6-AA04-E51F11F7D9A7@llnl.gov> (raw)
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




> 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


  reply	other threads:[~2022-02-06  9:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-05  1:19 Commit SHA1 == SHA1 checksum? Gamblin, Todd
2022-02-06  0:22 ` Philip Oakley
2022-02-06  9:00   ` Gamblin, Todd [this message]
2022-02-06 10:23     ` Johannes Sixt
2022-02-06 10:15   ` Junio C Hamano
2022-02-06 19:25     ` Philip Oakley
2022-02-06 20:02       ` Junio C Hamano
2022-02-06 21:33         ` Philip Oakley
2022-02-07  8:15           ` Gamblin, Todd
2022-02-07 13:15             ` Konstantin Ryabitsev
2022-02-07 21:08               ` Gamblin, Todd
2022-02-07 13:32         ` Konstantin Ryabitsev
2022-02-07 20:57           ` Junio C Hamano
2022-02-07 21:34             ` Konstantin Ryabitsev
2022-02-07 22:29               ` Gamblin, Todd
2022-02-07 22:46                 ` Konstantin Ryabitsev
2022-02-08  6:23                   ` Gamblin, Todd
2022-02-07 22:49               ` Junio C Hamano
2022-02-07 23:02                 ` Konstantin Ryabitsev

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=188C988E-F679-4AD6-AA04-E51F11F7D9A7@llnl.gov \
    --to=gamblin2@llnl.gov \
    --cc=git@vger.kernel.org \
    --cc=philipoakley@iee.email \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).