git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Aug 9, 2018, 01:43 UTC
Message-ID
<20180809014302.GB34639@genre.crustytoothpaste.net>
In-Reply-To
<xmqqzhxwcq2o.fsf@gitster-ct.c.googlers.com>
On Wed, Aug 08, 2018 at 05:59:43PM -0700, Junio C Hamano wrote:
Show 8 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> 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.

Show 12 quoted lines
> > 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
Previous: Junio C HamanoNext: Jeff King
Message 11 of 19 in “verify-tag/verify-commit should exit unsuccessfully when signature is not trusted”
  1. 1/1 verify-tag/verify-commit should exit unsuccessfully when signature is not trustedVojtech Myslivec, Jul 31, 2018
  2. brian m. carlsonAug 1, 2018
  3. Santiago TorresAug 1, 2018
  4. Karel KočíAug 3, 2018
  5. Santiago TorresAug 3, 2018
  6. Jeff KingAug 3, 2018
  7. Karel KočíAug 4, 2018
  8. Jeff KingAug 8, 2018
  9. brian m. carlsonAug 8, 2018
  10. Junio C HamanoAug 9, 2018
  11. brian m. carlsonAug 9, 2018
  12. Jeff KingAug 9, 2018
  13. Junio C HamanoAug 9, 2018
  14. Jeff KingAug 9, 2018
  15. Junio C HamanoAug 9, 2018
  16. Jeff KingAug 9, 2018
  17. brian m. carlsonAug 10, 2018
  18. Vojtech MyslivecAug 13, 2018
  19. Junio C HamanoAug 3, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.