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

Re: Proper plumbing for porcelain gpg formats on git show?

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Jan 19, 2015, 14:13 UTC
Message-ID
<54BD110E.2080801@drmicha.warpmail.net>
In-Reply-To
<6B1E582B25CD4722B8993C5A3C304ECA@black>
Jason Pyeron schrieb am 16.01.2015 um 21:05:
Show 67 quoted lines
>> -----Original Message-----
>> From: Junio C Hamano
>> Sent: Friday, January 16, 2015 14:53
>>
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>>> would there be interest in accepting a patch for 
>>>>
>>>> %Gs - the raw GPG text from the commit
>>>> %Gf - the key fingerprint
>>>
>>> There may be bikeshedding on the exact format specifier, but aside
>>> from that I don't see why not. ;-)
>>
>> I was about to say "As long as the execution is good, why not?
>> Spawning an extra process 'gpg --list-packets' is not quite
>> acceptable without properly being lazy is not acceptable".
>>
>> But verify_signed_buffer() reads "gpg --status-fd=1 --verify"
>> output, it is already done lazily in format_commit_one() only when
>> the "%G?" placeholder is used, and the output we parse that are
>> prefixed by [GNUPG:] should have enough information to grab the
>> fingerprint from on the VALIDSIG line.
>>
>> So I do not see a lot of room to screw-up the execution ;-).
> 
> This kind of begs the question of extracting signatures, not in one's keyring. I was surprised to see %GK fail because it was not yet in the keyring. I would also expect a "B", not a "N" for %G?, maybe there should be a "X" for can't verify.
> 
> $ gpg --delete-keys DA0848AD
> gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> 
> pub  2048R/DA0848AD 2014-06-24 Jason Pyeron <jpyeron@pdinc.us>
> 
> Delete this key from the keyring? (y/N) y
> 
> $ git diff-tree -s --format=%G? HEAD
> N
> 
> $ git diff-tree -s --format=%GG HEAD
> gpg: Signature made Fri 16 Jan 2015 01:33:12 PM EST using RSA key ID DA0848AD
> gpg: Can't check signature: No public key
> 
> 
> $ git diff-tree -s --format=%GK HEAD
> 
> $ gpg --keyserver hkp://pgp.mit.edu --recv-keys 8D6B5984DA0848AD
> gpg: requesting key DA0848AD from hkp server pgp.mit.edu
> gpg: key DA0848AD: public key "Jason Pyeron <jpyeron@pdinc.us>" imported
> gpg: Total number processed: 1
> gpg:               imported: 1  (RSA: 1)
> 
> $ git diff-tree -s --format=%G? HEAD
> U
> 
> $ git diff-tree -s --format=%GG HEAD
> gpg: Signature made Fri 16 Jan 2015 01:33:12 PM EST using RSA key ID DA0848AD
> gpg: Good signature from "Jason Pyeron <jpyeron@pdinc.us>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 8C88 9ECF 7A2F 7977 7CE9  13B4 8D6B 5984 DA08 48AD
> 
> 
> $ git diff-tree -s --format=%GK HEAD
> 8D6B5984DA0848AD

I'm not exactly sure what you are trying to extract, but "git verify-commit -v" gives you the actual signature, which you can then feed into gpg/gpgsplit for surgery according to taste.

As far as git goes, I think it should give you all gpg information that it has available but not morph into a gpg frontend or trust manager.

Ultimately, signature verification in its true meaning requires human inspection of the full gpg output.

Michael
Previous: Jason Pyeron
Message 5 of 5 in “Proper plumbing for porcelain gpg formats on git show?”
  1. Jason PyeronJan 16, 2015
  2. Jonathan NiederJan 16, 2015
  3. Junio C HamanoJan 16, 2015
  4. Jason PyeronJan 16, 2015
  5. Michael J GruberJan 19, 2015

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.