Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> This is v3 rebased on current next (the %G works by Jeff & Junio).
>
> Open questions:
>
> - Should one of git verify-{commit,tag} learn how to verify mergetags?
> (Probably no, it differs from both other cases.)
If we were to teach one of them, "verify-commit" as part of
"verifying what is recorded in the commit object", would be the
logical place to do so.
It is OK to implement only verification of signatures on commit
objects themselves, but we would need a plan for handling other
kinds of verifications later, so that we can give a stable output to
scripts.
If we decide to signal successful verification of the signature on
the commit itself one way in this implementation, that should
reliably be the way to do so even if we later add verification of
other aspects on the commit object (e.g. mergetags it carries). If
running "verify-commit $commit" and checking the zero-ness of its
exit status is the way, that should not change if later versions of
Git learns to verify mergetags as well; even if the given $commit
carries a mergetag that does not verify, as long as the signature in
the commit itself is valid, the script should continue to receive
"success" from the command.
> - Should we do this now or go for generic "git verify" right away?
I do not think we are ready to do "git verify" yet. We first need
to design how "verify-commit" should communicate failure/success
combinations of verification of a commit that has a signature on
itself and a mergetag on one of its parents, and of a commit that
has zero or one signature on itself and two or more mergetags on its
parents. Do we fail unless all of them are found to be valid? Do
we use bits in exit status? Output to the standard output, one line
per signature verified?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html