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

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