Re: [PATCH 1/1] verify-tag/verify-commit should exit unsuccessfully when signature is not trusted

From: Jeff King <peff@peff.net>
Date: Aug 3, 2018, 16:06 UTC
Message-ID: <20180803160634.GA19944@sigill.intra.peff.net>
In-Reply-To: <20180803154343.z3lgkudleood6lhs@LykOS.localdomain>

On Fri, Aug 03, 2018 at 11:43:44AM -0400, Santiago Torres wrote:

Show 12 quoted lines

> > This is not a deviation. GPG correctly recognizes difference between trusted,
> > untrusted and unknown levels. git on the other hand does not. Well it did until
> > the commit a4cc18f29. That one removed GPG exit code propagation.
> 
> Oh wow. Sorry my assumption parted from looking at the code back in the
> day where this happens. I assumed git was quietly propagating the gpg
> error code and took it from there. 
> 
> Now that I think about it though, verify tag can verify more than one
> tag. I assume that this would make it difficult to propagate individual
> errors in trusting. I honestly don't know what's the best way to modify
> this behavior then.

I think the only sensible thing is to err on the conservative side, and return non-zero if we saw _any_ invalid signature.

I will note, though, that just checking the exit code of `verify-tag` isn't really that thorough. It shows that there was _a_ signature, but we don't know:

  - if it was an identity the user would expect to be signing tags

  - if it even matches the refname we used to find the tag

So I'd argue that any real verification needs to either have a human in the loop, or implement a custom policy based on reading the full output.

I know we (and you specifically Santiago) talked about this a while ago, and we ended up providing ways to get more information out of verify-tag, so that a tool could sit on top of that and implement more project-specific policy. I don't know offhand of any reusable tools that do so, though.

-Peff