From: Philip Oakley <philipoakley@iee.email>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Gamblin, Todd" <gamblin2@llnl.gov>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Commit SHA1 == SHA1 checksum?
Date: Sun, 6 Feb 2022 21:33:14 +0000 [thread overview]
Message-ID: <13f21a57-1519-5ace-30e8-def598fad38b@iee.email> (raw)
In-Reply-To: <xmqqee4fix0l.fsf@gitster.g>
On 06/02/2022 20:02, Junio C Hamano wrote:
> 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.
Thanks for the clarification.
Thus what trust their is, is via the two PGP signatures, rather than
directly between the tarball and the git repo.
--
Philip
next prev parent reply other threads:[~2022-02-06 21:33 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
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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13f21a57-1519-5ace-30e8-def598fad38b@iee.email \
--to=philipoakley@iee.email \
--cc=gamblin2@llnl.gov \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.
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 NNTP newsgroup(s).