Thread (3 messages) flat view 3 messages, 2 authors, 2016-06-15

Re: [RFC PATCH] gpg: add support for gpgsm

From: Carlos Martín Nieto <hidden>
Date: 2016-06-15 23:09:08

On Thu, 2016-03-31 at 10:22 -0400, Jeff King wrote:
On Thu, Mar 31, 2016 at 03:51:44PM +0200, Carlos Martín Nieto wrote:
quoted
Detect the gpgsm block header and run this command instead of gpg.
This part makes sense to me, and is a strict improvement (though
offhand, I wonder if any other systems use the generic "BEGIN SIGNED
MESSAGE" header. The obvious option would be PEM from "openssl
smime",
but it is "BEGIN PKCS7").
Yep. It's useful when you can tell what generated the signatures.
quoted
On the signing side, ask gpgsm if it knows the signing key we're
trying
to use and fall back to gpg if it does not.
This part looks like we incur an extra fork/exec each time we sign
with
gpg, even if the user doesn't ever want to use gpgsm, or even have it
installed.
Yes, this is unfortunate as I don't know any other way to tell whether
gpgsm (or whatever else) knows about a key. We could try to find gpgsm
in PATH but I suspect this would be expensive as well.
I wonder if there are any hints we can use from the key ident, but I
suppose not. In the default config, it comes straight from
$GIT_COMMITTER_*, and is just a name/email.
Both gpg and gpgsm accept any string and try to match it against the
information in the keys. So even though gpgsm keys are shown by the
program itself with the "0x" prefix, 'gpgsm -k DigiCert' does show me
the public key I have for them.
But maybe we could pull this out to a separate config option, like
"commit.defaultSignatureType", which could be either "gpg", "gpgsm",
or
"auto" to enable the behavior you have here.  Then savvy users can
pick
the type they plan to use.  We can have a discussion then about
whether
to flip the default from "gpg" to "auto", but I'd vote to leave it at
gpg unless gpgsm gets a huge amount of traction, and it really is
50/50
what people would want.

And regardless of the default type for creating signatures, we'd
still
automatically verify signatures from either type.
This makes sense. It allows for the automatic detection if that's
wanted but it would stop us running gpgsm on each invocation.


quoted
 /*
+ * Try to figure out if the given program contains given the key.
Both
+ * gpg and gpgsm have keys in hex format, so we don't necessarily
know
+ * which one to use.
+ */
+static int program_knows_key(const char *program, const char
*signing_key)
+{
+	struct child_process gpg = CHILD_PROCESS_INIT;
+	struct strbuf output = STRBUF_INIT;
+	const char *args[4];
+	size_t len;
+
+	gpg.argv = args;
+	gpg.in = -1;
+	gpg.out = -1;
+	args[0] = program;
+	args[1] = "-K";
+	args[2] = signing_key;
+	args[3] = NULL;
I think you'd want to send stderr to /dev/null here, as this is for
speculatively seeing "does the user even have gpgsm set up?".
quoted
+
+	if (start_command(&gpg))
+		return error(_("could not run '%s'"), program);
Likewise, most users would start seeing "could not run 'gpgsm'" if
they
do not even have it installed.
Ah yes, I completely forgot to take that into account.

   cmn
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help