Re: [PATCH 0/5] refactor gpg-interface and add gpg verification for clones

From: Junio C Hamano <gitster@pobox.com>
To: Hans Jerry Illikainen <hji@dyntopia.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/5] refactor gpg-interface and add gpg verification for clones
Date: Sun, 05 Jan 2020 15:11:35 -0800	[thread overview]
Message-ID: <xmqq36ctbis8.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20200105135616.19102-1-hji@dyntopia.com> (Hans Jerry Illikainen's message of "Sun, 5 Jan 2020 13:56:11 +0000")

Hans Jerry Illikainen <hji@dyntopia.com> writes:

> And finally, signature verification is added to the clone builtin.  It
> obeys --(no-)verify-signatures, clone.verifySignatures and
> gpg.verifySignatures (in decreasing order of significance).

It is clear for a merge or a pull what it means to verify
signature---you trust your local history, and you are willing to
merge in a commit only when it has a trusted signature (which
automatically means that you trust the hash function and also the
signer did some reasonable vetting of the history behind the tip
commit, or you never check out your intermediate state, depending
on your threat model).

I am not sure what it should mean to verify signature on clone.  I'd
assume that our threat model and verification policy are consistent
with what we use for a merge/pull, in that we trust all history
behind a commit that has a trusted signature, so it is clear that
you would want the tip commit of the default branch (or if you are
naming a single branch to clone, then the tip of that branch) to
carry a trusted signature.  But what about the commits that are
reachable from other branches and tags that are *not* contained
in the branch that is initially checked out?

Later in the proposed log message of 5/5 you allude to risk of
merely checking out a potentially untrustworthy contents to the
working tree.  This is far stricter than the usual threat model we
tend to think about as the developers of source code management
system, where checking out is perfectly OK but running "make" or its
equivalent is the first contact between the victim's system with
malicious contents.

Verifying the tip of the default/sole branch upon cloning before the
tree of the commit is checked out certainly would cover that single
case (i.e. the initial checkout after cloning), but I am not sure if
it is the best way, and I am reasonably certain it is insufficient
against your threat model.  After such a clone is made, when the
user checks out another branch obtained from the "origin" remote,
there is no mechanism that protects the user from the same risk you
just covered with the new signature verification mechanism upon
cloning, without validating the tip of that other branch, somewhere
between the time the clone is made and that other branch gets
checked out.

It almost makes me suspect that what you are trying to do with the
"verification upon cloning" may be much better done as a "verify the
tree for trustworthyness before checking it out to the working tree"
mechanism, where the trustworthyness of a tree-ish object may be
defined (and possibly made customizable by the policy of the project
the user is working on) like so:

 - A tree is trustworthy if it is the tree of a trustworthy commit.

 - A commit is trustworthy if

   . it carries a trusted signature, or
   . it is pointed by a tag that carries a trusted signature, or
   . it is reachable from a trustworthy commit.

Now, it is prohibitively expensive to compute the trusttworthiness
of a tree, defined like the above, when checking it out, UNLESS you
force each and every commit to carry a trusted signature, which is
not necessarily practical in the real world.

Another approach to ensure that any and all checkout would work only
on a trustworthy tree might be to make sure that tips of *all* the
refs are trustworthy commits immediately after cloning (instead of
verifying only the branch you are going to checkout, which is what
your patch does IIUC).  That way, any subsequent checkout in the
repository would either be checking out a commit that was

 - originally cloned from the remote, and is reachable from some ref
   that was validated back when the repository was cloned, or

 - created locally in this repository, which we trust, or

 - fetched from somewhere else, and is reachable from the commit
   that was validated back when "git pull" validated what was about
   to be integrated into the history of *this* repository.

Hmm?