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

Re: [PATCHv3] gpg-interface: check gpg signature creation status

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Jun 15, 2016, 07:17 UTC
Message-ID
<75709ea6-b2bb-fddf-1175-cb8aae66629a@drmicha.warpmail.net>
In-Reply-To
<20160615005614.GB32601@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 15.06.2016 02:56:
Show 28 quoted lines
> On Tue, Jun 14, 2016 at 04:47:35PM -0700, Junio C Hamano wrote:
> 
>> Jeff King <peff@peff.net> writes:
>>
>>> I'm still undecided on whether it is a better approach than making
>>> sure the stdout we got looks sane. In particular I'd worry that it
>>> would make things harder for somebody trying to plug in something
>>> gpg-like (e.g., if you wanted to do something exotic like call a
>>> program which fetched the signature from a remote device or
>>> something).  But it's probably not _that_ hard for such a script
>>> to emulate --status-fd.
>>
>> I share the same thinking, but at the same time, it already is a
>> requirement to give --status-fd output that is close enough on the
>> signature verification side, isn't it?
> 
> Yeah, though I could see somebody wanting to sit amidst the signing side
> but not verification (e.g., if your keys are elsewhere from the machine
> running git). Of course such a case could probably ferry --status-fd
> from the other side anyway.
> 
> I admit I don't know of such a case in practice, though, and
> implementing a rudimentary --status-fd to say "SIG OK" or whatever on
> the signing side is not _that_ big a deal. So if we think this approach
> is a more robust solution in the normal case, let's not hold it up over
> what-ifs.
> 
> -Peff

As for the flexibility: We do code specifically for gpg, which happens to work for gpg2 also. The patch doesn't add any gpg ui requirements that we don't require elsewhere already. More flexibility requires a completely pluggable approach - gpgsm already fails to meet the gpg command line ui.

In any case, "status-fd" is *the* way to interface with gpg reliably just like plumbing commands are *the* way to interface with git reliably.

As for the read locking: I'm sorry I have no idea about that area at all. I thought that I'm doing the same that we do for verify, but apparently not. My strbuf_read-fu is not that strong either (read: copy&paste). I trust your assessment completely, though.

As for the original problem: That had a different cause, as we know now (rebase dropping signatures without hint). I still think we should check gpg status codes properly.

Michael
Previous: Jeff KingNext: Jeff King
Message 20 of 31 in “I lost my commit signature”
  1. ZhenTianJun 14, 2016
  2. Jeff KingJun 14, 2016
  3. ZhenTianJun 14, 2016
  4. Jeff KingJun 14, 2016
  5. ZhenTianJun 14, 2016
  6. Jeff KingJun 14, 2016
  7. ZhenTianJun 14, 2016
  8. Michael J GruberJun 14, 2016
  9. gpg-interface: check gpg signature for correct headerMichael J Gruber, Jun 14, 2016
  10. Jeff KingJun 14, 2016
  11. Michael J GruberJun 14, 2016
  12. Michael J GruberJun 14, 2016
  13. [PATCHv2] gpg-interface: check gpg signature for correct headerMichael J Gruber, Jun 14, 2016
  14. [PATCHv3] gpg-interface: check gpg signature creation statusMichael J Gruber, Jun 14, 2016
  15. Junio C HamanoJun 14, 2016
  16. Jeff KingJun 14, 2016
  17. Jeff KingJun 14, 2016
  18. Junio C HamanoJun 14, 2016
  19. Jeff KingJun 15, 2016
  20. Michael J GruberJun 15, 2016
  21. Jeff KingJun 16, 2016
  22. Michael J GruberJun 16, 2016
  23. Jeff KingJun 15, 2016
  24. ZhenTianJun 15, 2016
  25. Jeff KingJun 15, 2016
  26. Michael J GruberJun 15, 2016
  27. ZhenTianJun 15, 2016
  28. Jeff KingJun 16, 2016
  29. Junio C HamanoJun 16, 2016
  30. Michael J GruberJun 17, 2016
  31. Junio C HamanoJun 17, 2016

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.