On Wed, Aug 08, 2018 at 05:59:43PM -0700, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > >> FWIW, I'm on board with returning non-zero in any case where gpg would. > > > > I think that's probably the best solution overall. > > FWIW, I am not married to the current behaviour. I would not be > surprised if it mostly came by accident and not designed. Since apparently I was the author of the commit that changed the behavior originally, let me simply say that I was not aware that gpg signalled the correctness of a signature by its exit status when I wrote that patch. If I had known that, I would have deferred to gpg in my change. My goal was consistency between verify-tag and verify-commit, and in retrospect I probably made the wrong decision. > > 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: > > The last bit is a bit questionable; I think you are reading too much > into the description. > > A substitute for gpg.program MUST signal good (or not good) > signature the same way as gpg would with its exit code---that is all > the description says. It does not say anything about how that exit > code affects the exit status of "tag --verify" and friends that > called gpg.program. I agree that the description doesn't specifically say that. In fact, it doesn't explicitly say that it must exit nonzero on a bad signature, although I agree with your interpretation that that would be logical (and, AIUI, the behavior of gpg). However, I would assert that we do want Git's verification to exit successfully on a good signature and unsuccessfully on a bad signature, and deferring to gpg may be the most robust way of ensuring that. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
