On Fri, Dec 14, 2018 at 6:10 PM John Passaro wrote: > All seems to work fine when I treat %Gs as a detached signature. In light of this, my best guess as to why the cleartext PGP message didn't verify properly is that the commit data normally doesn't end with \n, but as far as I can tell there's no way to express that in the cleartext format. I don't see a way around this. However, as long as the following works, I think we have proof-of-concept that this enhancement allows you to play with signature data however you please without leaving it to git under the hood: gpg --verify <(git show -s --format=format:%Gs commit) <(git show -s --format=format:%Gp commit) On Mon, Dec 17, 2018 at 3:24 PM Jeff King <peff@xxxxxxxx> wrote: > > On Fri, Dec 14, 2018 at 11:07:03AM -0500, John Passaro wrote: > > > Then I might rename the other new placeholders too: > > > > %Gs: signed commit signature (blank when unsigned) > > %Gp: signed commit payload (i.e. in practice minus the gpgsig header; > > also blank when unsigned as well) > > One complication: the pretty-printing code sees the commit data in the > i18n.logOutputEncoding charset (utf8 by default). But the signature will > be over the raw commit data. That's also utf8 by default, but there may > be an encoding header indicating that it's something else. In that case, > you couldn't actually verify the signature from the "%Gs%Gp" pair. > > I don't think that's insurmountable in the code. You'll have to jump > through a few hoops to make sure you have the _original_ payload, but we > obviously do have that data. However, it does feel a little weird to > include content from a different encoding in the middle of the log > output stream which claims to be i18n.logOutputEncoding. > Thanks for the feedback! This is an interesting conflict. If the user requests %Gp, the payload for the signature, they almost certainly do want it in the original encoding; if i18n.logOutputEncoding is something incompatible, whether explicitly or by default, that seems like an error. Not much we can do to reconcile the two requests (commit encoding vs output encoding) so seems reasonable to treat it as fatal. Updated patch coming as soon as I work out Peff's aforementioned "few hoops" to get properly encoded data -- and also how to test success and failure!
