[PATCH v2] log: Read gpg settings for signed commit verification

[PATCH v2] log: Read gpg settings for signed commit verification

[Hans Brigman]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

From: Jacob Sarvis<jsarvis@openspan.com>

log: Read gpg settings for signed commit verification

Commit signature verification fails when alternative gpg.program
signs the commit, but gpg attempts to verify the signature.
"show --show-signature" and "log --show-signature" do not read
the gpg.program setting from git config.
Commit signing, tag signing, and tag verification use this setting
properly.

Make log and show commands pass through settings to gpg interface.

Signed-off-by: Hans Brigman <hbrigman@openspan.com>
---
 builtin/log.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/builtin/log.c b/builtin/log.c
index 8f0b2e8..31f5a9e 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -23,6 +23,7 @@
 #include "streaming.h"
 #include "version.h"
 #include "mailmap.h"
+#include "gpg-interface.h"
 
 /* Set a default date-time format for git log ("log.date" config variable) */
 static const char *default_date_mode = NULL;
@@ -364,7 +365,8 @@ static int git_log_config(const char *var, const char *value, void *cb)
 		use_mailmap_config = git_config_bool(var, value);
 		return 0;
 	}
-
+	if (git_gpg_config(var, value, cb) < 0)
+		return -1;
 	if (grep_config(var, value, cb) < 0)
 		return -1;
 	return git_diff_ui_config(var, value, cb);
-- 
1.7.11.msysgit.0


On Mon, Mar 25, 2013 at 01:03:52PM -0500, Hans Brigman wrote:

> "show --show-signature" doesn't currently use the gpg.program setting.  Commit signing, tag signing, and tag verification currently use this setting properly, so the logic has been added to handle it here as well.

Please wrap your commit messages at something reasonable (70 is probably as high as you want to go, given that log output is often shown indented).

> @@ -364,7 +365,8 @@ static int git_log_config(const char *var, const char *value, void *cb)
>  		use_mailmap_config = git_config_bool(var, value);
>  		return 0;
>  	}
> -
> +	if (!prefixcmp(var, "gpg."))
> +		return git_gpg_config(var, value, NULL);
>  	if (grep_config(var, value, cb) < 0)
>  		return -1;

The gpg config can also be other places than "gpg.*". Right now it is just user.signingkey, which log would not care about, but it feels like we are depending an unnecessary detail here. We also don't know whether it would care about the callback data. Is there a reason not to do:

  if (git_gpg_config(var, value, cb) < 0)
          return -1;

just like the grep_config call below?

-Peff

[-- Attachment #2: 0001-log-Read-gpg-settings-for-signed-commit-verification.patch --]
[-- Type: application/octet-stream, Size: 1424 bytes --]

From 960175cb3326a12e038805121edbdc8119fbb104 Mon Sep 17 00:00:00 2001
From: Jacob Sarvis <jsarvis@openspan.com>
Date: Fri, 22 Mar 2013 12:54:32 -0400
Subject: [PATCH 1/2] log: Read gpg settings for signed commit verification

Commit signature verification fails when alternative gpg.program
signs the commit, but gpg attempts to verify the signature.
"show --show-signature" and "log --show-signature" do not read
the gpg.program setting from git config.
Commit signing, tag signing, and tag verification use this setting
properly.

Make log and show commands pass through settings to gpg interface.

Signed-off-by: Jacob Sarvis <jsarvis@openspan.com>
---
 builtin/log.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/builtin/log.c b/builtin/log.c
index 8f0b2e8..31f5a9e 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -23,6 +23,7 @@
 #include "streaming.h"
 #include "version.h"
 #include "mailmap.h"
+#include "gpg-interface.h"
 
 /* Set a default date-time format for git log ("log.date" config variable) */
 static const char *default_date_mode = NULL;
@@ -364,7 +365,8 @@ static int git_log_config(const char *var, const char *value, void *cb)
 		use_mailmap_config = git_config_bool(var, value);
 		return 0;
 	}
-
+	if (git_gpg_config(var, value, cb) < 0)
+		return -1;
 	if (grep_config(var, value, cb) < 0)
 		return -1;
 	return git_diff_ui_config(var, value, cb);
-- 
1.7.11.msysgit.0

Re: [PATCH v2] log: Read gpg settings for signed commit verification

[Junio C Hamano]

Hans Brigman <hbrigman@openspan.com> writes:

> Content-Type: multipart/mixed; boundary="_002_8C726954D36902459248B0627BF2E66F45D70C3E4EAUSP01VMBX10c_"

No multipart/anything please.  We prefer to see text/plain.

In general, please follow Documentation/SubmittingPatches.

> From: Jacob Sarvis<jsarvis@openspan.com>

Missing SP between name and e-mail.

>
> log: Read gpg settings for signed commit verification

That's the same as the e-mail subject; drop it.

>
> Commit signature verification fails when alternative gpg.program
> signs the commit, but gpg attempts to verify the signature.
> "show --show-signature" and "log --show-signature" do not read
> the gpg.program setting from git config.
> Commit signing, tag signing, and tag verification use this setting
> properly.
>
> Make log and show commands pass through settings to gpg interface.
>
> Signed-off-by: Hans Brigman <hbrigman@openspan.com>

Needs the author's Sign-off before yours.

> ---
>  builtin/log.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index 8f0b2e8..31f5a9e 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -23,6 +23,7 @@
>  #include "streaming.h"
>  #include "version.h"
>  #include "mailmap.h"
> +#include "gpg-interface.h"
>  
>  /* Set a default date-time format for git log ("log.date" config variable) */
>  static const char *default_date_mode = NULL;
> @@ -364,7 +365,8 @@ static int git_log_config(const char *var, const char *value, void *cb)
>  		use_mailmap_config = git_config_bool(var, value);
>  		return 0;
>  	}
> -
> +	if (git_gpg_config(var, value, cb) < 0)
> +		return -1;
>  	if (grep_config(var, value, cb) < 0)
>  		return -1;

Hmph.  I do not particularly like the way the call to grep_config()
loses information by not ignoring its return value and always
returning -1, but I'll let it pass for this patch.

>  	return git_diff_ui_config(var, value, cb);

Re: [PATCH v2] log: Read gpg settings for signed commit verification

[Jeff King]

On Wed, Mar 27, 2013 at 09:15:58AM -0700, Junio C Hamano wrote:

> >  	}
> > -
> > +	if (git_gpg_config(var, value, cb) < 0)
> > +		return -1;
> >  	if (grep_config(var, value, cb) < 0)
> >  		return -1;
> 
> Hmph.  I do not particularly like the way the call to grep_config()
> loses information by not ignoring its return value and always
> returning -1, but I'll let it pass for this patch.

That's my fault for suggesting he follow the same style as grep here.
But I wonder if it is worth the effort. We have never cared about
anything beyond "was there an error" in our config callbacks, and the
value returned from the callbacks is lost in git_parse_file (i.e., we do
not propagate the actual return value, but only check that
"callback(var, value, data) < 0", and die if so).

Existing callbacks pass data out by writing into a struct pointed to by
the data pointer, which is more flexible, anyway.

So unless you want to overhaul the whole config system to propagate
return codes back to the caller, I do not think there is any point in
worrying about it.

-Peff

Re: [PATCH v2] log: Read gpg settings for signed commit verification

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Mar 27, 2013 at 09:15:58AM -0700, Junio C Hamano wrote:
>
>> >  	}
>> > -
>> > +	if (git_gpg_config(var, value, cb) < 0)
>> > +		return -1;
>> >  	if (grep_config(var, value, cb) < 0)
>> >  		return -1;
>> 
>> Hmph.  I do not particularly like the way the call to grep_config()
>> loses information by not ignoring its return value and always
>> returning -1, but I'll let it pass for this patch.
>
> That's my fault for suggesting he follow the same style as grep here.
> But I wonder if it is worth the effort. We have never cared about
> anything beyond "was there an error" in our config callbacks, and the
> value returned from the callbacks is lost in git_parse_file (i.e., we do
> not propagate the actual return value, but only check that
> "callback(var, value, data) < 0", and die if so).
>
> Existing callbacks pass data out by writing into a struct pointed to by
> the data pointer, which is more flexible, anyway.
>
> So unless you want to overhaul the whole config system to propagate
> return codes back to the caller, I do not think there is any point in
> worrying about it.

Yeah, that is where my conclusion in the message you are responding
comes from ;-)