Re: Commit SHA1 == SHA1 checksum?

[Junio C Hamano <gitster@pobox.com>]

Philip Oakley <philipoakley@iee.email> writes:

> 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...

That's how a signed tag protects the commit it points at, and
everything reachable from it.  As much or as little trust you have
in SHA-1 in validating tarball.tar with its known SHA-1 checksum,
you can trust to the same degree that the commit that is pointed by
a tag is what the person who signed (with GPG) the tag wanted the
tag to point at, and in turn the trees and blobs in that commit are
what the signer wanted to have in that tagged commit, ad infinitum,
in the space dimension.  At the same time, a commit object records
the hash of the commit objects that are its parents, the whole
history of the project going back to inception can be trusted to the
same degree in the time dimension.

> https://lore.kernel.org/git/xmqqh7n5zv2b.fsf@gitster.c.googlers.com/ is
> a recent discussion on the refreshing of the PGP key. the post
> https://lore.kernel.org/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."

That thread has very little to do with the way how Git objects are
cryptographically protected, which I discussed earlier in this
message.

Instead, it was a discussion about how the checksum files and
tarballs at

    https://www.kernel.org/pub/software/scm/git/

relate to each other.  A typical release tarball for Git version
$VERSION has multiple tarballs git-$VERSION.tar.{gz,bz2,xz,...} and
they all uncompresses back to the same git-$VERSION.tar tarball.

There is git-$VERSION.tar.sign file next to them in the same
directory.  The file is supposed to contain a detached signature
over the uncompressed version of the archive.