All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	git@vger.kernel.org, jpyeron@pdinc.us
Subject: Re: Proper plumbing for porcelain gpg formats on git show?
Date: Mon, 19 Jan 2015 15:13:34 +0100	[thread overview]
Message-ID: <54BD110E.2080801@drmicha.warpmail.net> (raw)
In-Reply-To: <6B1E582B25CD4722B8993C5A3C304ECA@black>

Jason Pyeron schrieb am 16.01.2015 um 21:05:
>> -----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

      reply	other threads:[~2015-01-19 14:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16 16:57 Proper plumbing for porcelain gpg formats on git show? Jason Pyeron
2015-01-16 19:29 ` Jonathan Nieder
2015-01-16 19:52   ` Junio C Hamano
2015-01-16 20:05     ` Jason Pyeron
2015-01-19 14:13       ` Michael J Gruber [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54BD110E.2080801@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jpyeron@pdinc.us \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.