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@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ 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
Attachment:
signature.asc
Description: PGP signature
