On Mon, May 07, 2018 at 05:45:00AM -0400, Jeff King wrote: > Isn't that basically what this patch is, though? Or at least a step in > that direction? For generic signing support, you need: > > 1. A way to tell Git to recognize that a signature exists, and what > type it is. > > 2. A way to tell Git how to invoke the signing tool. > > Let me discuss (2) first. In your git-sign-* world, then (2) requires > us to define a set interface to those helpers, including which action to > perform, which key to use, etc. And then the logic is inside the helper > to translate that to the tool's interface. > > The direction I anticipated for this patch was more like: > > - for now, we just piggy-back on gpg's interface for interacting with > sub-programs. That makes gpgsm Just Work, and it means that you can > plug in any other tool by writing a wrapper which converts from gpg > options to the tool's interface. I.e., gpg's "-bsau" becomes the > lingua franca, rather than us inventing a new one. > > - the config schema leaves room for adding new properties to each tool. > So eventually we could support other option microformats by adding > signingtool.foo.interface = "signify" or whatever. > > That still leaves room if we want to design our own helper interface. > One thing we could do that this patch doesn't is require the user to > explicitly ask for "interface = gpg" (and set it by default for the > gpg tool stanza). And then leave it as an error if you have a tool > config that doesn't specify its interface type, which leaves room for > us later to make that default our generic interface. > > Getting back to (1), how do we tell Git to recognize a signature? I > think we have to use config here, since it would not know to invoke a > helper without recognizing the type (and we certainly do not want to > speculatively invoke each helper saying "do you understand this?" for > efficiency reasons). I think my main objection to this series is that it is generic in a way that isn't necessarily useful. We know there are essentially only two formats of PEM-style signatures: OpenPGP and CMS[0]. Even if there are more, they aren't intrinsically useful, because our codebase can only handle GnuPG-style tools, and those are the only formats GnuPG-style tools really support (although, as you point out, other tools could mimic the interface). I think if we aren't going to implement some sort of interface that's generically useful for all signing tools, it would be better to simply say that we support gpg and gpgsm and have signingtool.gpg.program and signingtool.gpgsm.program and hard-code the logic for those two formats. That way we don't have a generic interface that's really only useful for PEM-style tools, when we know it likely won't be useful for other tools as well. We can add a more generic interface when we have more varied tools to support and we know more about what the requirements will be. This doesn't address Junio's concern about whether adding CMS support is the right direction to go. I personally think OpenPGP is the right direction for most open-source projects, but I know some companies want to use CMS internally and I'm not intrinsically opposed to that[1]. That decision is ultimately up to Junio, though. [0] I'm ignoring the original PEM, which specifies MD2 and MD5, algorithms that nobody should be using these days. [1] I would welcome, though, if one could configure only one type of signature verification by, say, setting the signing program to /bin/false in the config. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
