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@xxxxxxxxxxxxxxxxxxxxxx/ is > a recent discussion on the refreshing of the PGP key. the post > https://lore.kernel.org/git/YA3nwFcYz4tbhrlO@xxxxxxxxxxxxxxxxxxxxxxxxx/ > 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.
