Re: Commit SHA1 == SHA1 checksum?

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 6, 2022, 20:02 UTC
Message-ID: <xmqqee4fix0l.fsf@gitster.g>
In-Reply-To: <eca83634-ee91-89bd-567e-6b0807b5ff79@iee.email>

Philip Oakley <philipoakley@iee.email> writes:

> I think part of Todd's question was how the tag and uncompressed archive
> 'checksums' (e.g. hashes) relate to each other and where those
> guarantees come from.

There is no such linkage, and there are no guarantees. The trust you may or may not have on the PGP key that signs the tag and the checksums of the tarball is the only source of such assurance.

More importantly, I do not think there can be any such linkage between the Git tree and release tarball for a few fundamental reasons:

 * We add generated files to "git archive" output when creating the
   release tarball for builder's convenience, so if you did

       rm -fr temp && git init temp
       tar Cxf temp git-$VERSION.tar
       git -C temp add . && git -C temp write-tree

   the tree object name that you get out of the last step will not
   match the tree object of the version from my archive (interested
   parties can study "make dist" for more details).

 * Even if we did not add any files to "git archive" output when
   creating a release tarball, a tarball that contains all the
   directories and files from a given git revision is *NOT* unique.
   We do not add randomness to the "git archive" output, just to
   make them unstable, but we have made fixes and improvements to
   the archive generation logic in the past, and we do reserve the
   rights to do so in the future.  And it is not just limited to
   "git archive" binary, but how it is driven, e.g. "tar.umask"
   settings can affect the mode bits.