Re: [PATCH v2 0/9] X509 (gpgsm) commit signing support

From: Jeff King <peff@peff.net>
Date: Jul 16, 2018, 21:32 UTC
Message-ID: <20180716213210.GI25189@sigill.intra.peff.net>
In-Reply-To: <20180714183312.GG1042117@genre.crustytoothpaste.net>

On Sat, Jul 14, 2018 at 06:33:12PM +0000, brian m. carlson wrote:

Show 13 quoted lines

> > This series is a fine replacement for that earlier work. It's flexible
> > enough to allow what we really wanted out of that series (gpgsm support,
> > or another drop-in tool that uses the same interface). It doesn't lay
> > any groundwork for further tools (like signify), but I think the
> > consensus on the list was to punt on that until somebody had more
> > concrete plans for adding such a tool.
> 
> I actually think this moves in a nice direction for adding support for
> minisign/signify and other schemes.  There's a way to look up what
> algorithm is in use in a particular context based on the first line and
> a general interface for deciding what format to write.  Granted, it
> currently still is very specific to gpg-style tools, but I think this is
> an improvement in that regard.

My issue with this for helping with signify is that it creates a new gpg.<tool>.* hierarchy with two slots (openpgp and x509). But we would not want gpg.signify.program, would we? That makes no sense, as neither the signature-matching nor the program invocation are gpg-like.

But if we later moved to "signingtool.<tool>.*", now we have an extra layer of compatibility to deal with. E.g., signingtool.openpgp.program is the same as gpg.openpgp.program which is the same as gpg.program.

I think we can do that, but it means more historical baggage.

I'm OK with that since signify support is purely hypothetical at this point. But that's why I say that this doesn't lay the groundwork in the way that the other series did.

> As an OpenPGP user, I have no interest in adding support for other
> tools, but I think this should make it easier if someone else wants to
> do that.

I don't plan to work on signify (or other tools) anytime soon either. My interest here is in x509, since that's what enterprises would use over pgp.

I actually dislike pgp for this application, too, because I find the key management kind of complicated and tedious. But at least it's a standard among open source folks.

-Peff