On Wed, 2018-12-19 at 00:59 -0500, John Passaro wrote: > 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. You are most likely right. I've just skimmed through RFC 4880 and indeed it seems to rely on the newline encoding being quite normalized in the message. > 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) That's a nice trick. Thanks for the effort you're putting into this! > > 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! -- Best regards, Michał Górny
Attachment:
signature.asc
Description: This is a digitally signed message part
