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

[Jeff King <peff@peff.net>]

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

> 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.

> > 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.

> > 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