Hans Jerry Illikainen <hji@xxxxxxxxxxxx> 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?
