Re: [PATCH 8/8] gpg-interface: handle alternative signature types

From: Jeff King <peff@peff.net>
Date: May 9, 2018, 08:03 UTC
Message-ID: <20180509080341.GB3327@sigill.intra.peff.net>
In-Reply-To: <20180508230922.GB275488@genre.crustytoothpaste.net>

On Tue, May 08, 2018 at 11:09:22PM +0000, brian m. carlson wrote:

Show 10 quoted lines

> On Tue, May 08, 2018 at 09:28:14AM -0400, Jeff King wrote:
> > OK, so my question then is: what does just-gpgsm support look like?
> > 
> > Do we literally add gpgsm.program? My thought was that taking us the
> > first step towards a more generic config scheme would prevent us having
> > to backtrack later.
> 
> I think the signingtool prefix is fine, or something similar.  My "just
> gpgsm" proposal is literally just "check for PGP header" and "check for
> CMS header" in parse_signature and dispatch appropriately.

Hmm. I suppose that would work. I just didn't want to go the route of adding more hard-coded magic that the user couldn't override (or anything that is more complex than what the user could specify for their own tool if they wanted to). But I suppose there's probably not a big need to override the GPG or CMS matching in practice.

Show 8 quoted lines

> > There are also more CMS signers than gpgsm (and I know Ben is working on
> > a tool). So it feels a little ugly to make it "gpgsm.program", since it
> > really is a more generic format.
> 
> Okay, so signingtool.cms.program?  signingtool.smime.program?
> 
> I suppose Ben still intends to use the same command-line interface as
> for gpgsm.

AFAIK, yes.

Show 6 quoted lines

> > Or would you be happy if we just turned the matcher into a whole-line
> > substring or regex match?
> 
> A first line regex would probably be fine, if you want to go that way.
> That, I think, is generic enough that we can make use of it down the
> line, since it distinguishes all known formats, TTBOMK.

That seems like a happy medium to me. I worried at first that a regex might be noticeably expensive, but probably not. During "git log" we only feed "gpgsig" headers from each commit to the signature parsing code (so it's few lines, and no cost when you aren't using signatures). For tags we have to scan the whole tag body, but per-tag performance is much less important there, because you're not typically traversing hundreds of thousands of them.

> It would be nice if we could still continue to use gpg without having to
> add specific configuration for it, at least for compatibility reasons.

Definitely. Maintaining compatibility with the existing out-of-the-box behavior and with the existing config options is non-negotiable (and is already the case with the existing patch under discussion).

-Peff