On Fri, Aug 03, 2018 at 11:43:44AM -0400, Santiago Torres wrote: > > 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
