From: Jeff King <peff@peff.net>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: git@vger.kernel.org
Subject: Re: Is git clone followed by git verify-tag meaningful?
Date: Thu, 29 Aug 2019 10:10:11 -0400 [thread overview]
Message-ID: <20190829141010.GD1797@sigill.intra.peff.net> (raw)
In-Reply-To: <20190829133457.GA26173@chatter.i7.local>
On Thu, Aug 29, 2019 at 09:34:57AM -0400, Konstantin Ryabitsev wrote:
> As you know, for the Linux kernel we provide both tag signatures and
> detached PGP signatures on tarballs (and the same is true for git). The
> argument I hear frequently is that providing detached tarball signatures is
> redundant[*] when tags are already PGP-signed, so I wanted to double-check
> that all checksums are computed and matched on the client in the process of
> "git checkout" and we're not just verifying a signature of a non-verified
> checksum.
>
> In other words, I needed to double-check that what we get in the end is
> assurance that "all files in this repository are exactly the same as on the
> developer's system at the time when they ran 'git tag -s'."
Then yes, there is no need to fsck. When the objects were received on
the server side (by push) and then again when you got them from the
server (by clone), their sha1s were recomputed from scratch, not
trusting the sender at all in either case.
(Again, assuming you trust sha1; I think you should, especially since we
use the collision-detecting sha1 by default, but I wanted to make that
part clear).
> > Even without the fsck, we will compute the sha1 of each object (we must,
> > because the other side doesn't send it at all), and that we have all
> > objects reachable from the refs. So verifying the tag at that point
> > demonstrates a signature on the tag object, which refers to probably
> > some commit via sha1, which refers to actual trees and blobs by a chain
> > of sha1s. If you believe in the integrity of sha1, then it has
> > effectively signed all of that content.
>
> So, the client will actually calculate those checksums during the checkout
> stage to make sure that all content in the repository matches the hash of
> the commit being checked out, correct?
It's not during the checkout itself, but rather during the transfer of
objects into the receiving repository. I.e., there is no need to even
have a checkout. E.g., you could verify the tag and then use "git
archive".
Do note that both archive and checkout can modify files from their
in-repository state using gitattributes (e.g., to do line-ending
conversion, or using export-subst to add things like the commit ID into
the generated tarball). So it's possible that a tarball (either
generated from git-archive or from checked out contents) may not be
byte-for-byte identical.
Depending on your use case, that can range from an annoyance to ignore
(if a developer is using those features, tell them not to do that) to a
security issue (if you are somehow certifying the tarball contents based
on the tag signature, there is room for a malicious signer to tweak the
tarball contents).
But I think your question is mostly just "if I clone the repo and verify
the tag, is it what the original person signed?". And that answer is
yes.
-Peff
next prev parent reply other threads:[~2019-08-29 14:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-28 20:32 Is git clone followed by git verify-tag meaningful? Konstantin Ryabitsev
2019-08-28 23:27 ` brian m. carlson
2019-08-28 23:47 ` Jeff King
2019-08-29 13:34 ` Konstantin Ryabitsev
2019-08-29 14:10 ` Jeff King [this message]
2019-08-29 3:41 ` Junio C Hamano
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=20190829141010.GD1797@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=konstantin@linuxfoundation.org \
/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).