Re: Is git clone followed by git verify-tag meaningful?

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

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> If I know that a project uses tag signing, would "git clone" followed
> by "git verify-tag" be meaningful without a "git fsck" in-between?
> I.e. if an attacker has control over the remote server, can they sneak
> in any badness into any of the resulting files and still have the
> clone, checkout, and verify-tag return success unless the repository
> is fsck'd before verify-tag?
>
> I assume that it would break during the checkout stage, but I wanted
> to verify my assumptions.

What you are trusting and what you are trying to protect?

I am assuming that you are cloning and a commit that has a signed
tag is at the tip of the default branch, which gets checked out and
you want to make sure that what you see in the working tree after
checkout is healthy.  I also assume that you trust your local
machine, its Git and GPG binary included, and also you trust that
the underlying hash function Git uses has not been exploited for
this particular repository.

verify-tag would tell you that the tag you specify is signed by
which GPG key you have in your keychain.  Since tag records the
commit object name, you can check it against the HEAD.  As long
as you trust the underlying hash function and your local Git,
the trust flows from the HEAD's commit object name down to each
and every file checked out to the working tree.  As long as you
did not get any error from checkout, no fsck is needed here.

If your project is high-valued target like the Linux kernel, it is
probably a good idea to enable fetch.fsckobjects so that the
incoming objects are automatically checked while receiving over the
wire.