On Wed, Aug 08, 2018 at 07:04:56PM -0400, Jeff King wrote: > On Sat, Aug 04, 2018 at 10:43:46AM +0200, Karel Kočí wrote: > > I have a solution for my problem (calling git verify-* twice and grep). That is > > not the point of this email nor this contribution. The point is that although > > GPG's behavior of exiting with 0 code when trust level is unknown is unexpected > > but in the end understandable, git's behavior of exiting with 0 code even if key > > is explicitly untrusted is just counterintuitive. I think that few people are > > still going to get nasty surprise when I consider that this change was introduced > > mid 2014 just after v2.4.0 and Ubuntu 14.04 lts (running even on part of our > > infrastructure) still contains version 1.9.1 and in that release it was > > acknowledging GPG exit code. > > FWIW, I'm on board with returning non-zero in any case where gpg would. I think that's probably the best solution overall. There's a bug report in Debian (https://bugs.debian.org/895048) that requests that behavior instead of the status quo, and also it's the behavior that's documented: gpg.program Use this custom program instead of "gpg" found on $PATH when making or verifying a PGP signature. The program must support the same command-line interface as GPG, namely, to verify a detached signature, "gpg --verify $file - <$signature" is run, and the program is expected to signal a good signature by exiting with code 0, and to generate an ASCII-armored detached signature, the standard input of "gpg -bsau $key" is fed with the contents to be signed, and the program is expected to send the result to its standard output. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
