Hi Santiago--

On Wed 2019-03-20 10:20:57 -0400, Santiago Torres Arias wrote:
> This has been known for a whlie now[1]. The consensus back then was that
> this information was up to higher-level integrators to verify using
> means like e.g., --format.
>
> [1] https://public-inbox.org/git/xmqqk2hzldx8.fsf@gitster.mtv.corp.google.com/

Thanks for this pointer to the history!  Glad to see people have pushed
on it in the past, even if i don't think the place that conversation
wound down to is the right place to settle.

> This is implemented in for example pacman/devtools here[2].
>
> [2] https://lists.archlinux.org/pipermail/pacman-dev/2017-September/022123.html

Sigh.  This is exactly the kind of redundant implementation situation
that i'm afraid of getting into.  as the comment in that patch says:

    This really should be fixed in git itself, rather than forcing all
    downstream users of git verify-tag to implement their own checks,

Git gets to decide what choices to make here about what the default
verification process is, and the default verification step should be
sensible and narrowly aligned to the standard case associated with
revision control tag verification.

gpg and gpgv can both be used to confirm the validity of the signature,
but those tools don't (and architecturally can't) know that they're
being used in the context of git -- so it's important that git supplies
that domain-specific knowledge to the verification step.

fwiw, i'm pushing for comparable checks in the git-buildpackage

   https://bugs.debian.org/925118

but it seems pretty silly (and likely error-prone) to have to rewrite
the same check in every tool that uses "git tag -v".

> We published a paper with a more thorough security model here[3], and
> there's some stalled work into implementing this using push
> certificates...
>
> [3] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias

I'm not convinced that push certificates solves this problem, if i'm
understanding the work right.  push certificates have to do specifically
with the ability to push to a repository, but here we're talking about
arbitrary verifiers who have passive (read-only) access to a repository
wanting to verify a given tag.

If you're talking about using a push certificate as a substitute for a
signed tag itself, then that sounds like we're giving up on signed tags
meaning what everyone expects them to mean, all because we can't get the
verification process to work right.  That doesn't seem like a good
outcome.

Thanks for talking through this -- hopefully we can figure out a good
way forward.

       --dkg