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

[Junio C Hamano <gitster@pobox.com>]

Ben Toews <mastahyeti@gmail.com> writes:

> From: Ben Toews <btoews@github.com>
>
> Currently you can only sign commits and tags using "gpg".
> ...
> have asked before on the list about using OpenBSD signify).
> ---

Missing sign-off.

> -gpg.program::
> -	Use this custom program instead of "`gpg`" found on `$PATH` when
> -	making or verifying a PGP signature. The program must support the
> -	same command-line interface as GPG, namely, to verify a detached
> -	signature, "`gpg --verify $file - <$signature`" is run, and the
> -	program is expected to signal a good signature by exiting with
> -	code 0, and to generate an ASCII-armored detached signature, the
> -	standard input of "`gpg -bsau $key`" is fed with the contents to be
> +signingtool.<name>.program::
> +	The name of the program on `$PATH` to execute when making or
> +	verifying a signature.

I think you do not want "on `$PATH`", as you should be able to
specify a full path /opt/some/where/not/on/my/path/pgp and have it
work just fine.  The mention of "found on `$PATH`" in the original
is talking about the behaviour _WITHOUT_ the configuration, i.e. by
default we just invoke "gpg" and expect that it is found in the
usual measure, i.e. being on user's $PATH.  What you are describing
in this updated explanation is what happens _WITH_ the configuration.

> +	This program will be used for making
> +	signatures if `<name>` is configured as `signingtool.default`.
> +	This program will be used for verifying signatures whose PEM
> +	block type matches `signingtool.<name>.pemtype` (see below). The
> +	program must support the same command-line interface as GPG.
> +	To verify a detached signature,
> +	"`gpg --verify $file - <$signature`" is run, and the program is
> +	expected to signal a good signature by exiting with code 0.
> +	To generate an ASCII-armored detached signature, the standard
> +	input of "`gpg -bsau $key`" is fed with the contents to be
>  	signed, and the program is expected to send the result to its
> -	standard output.
> +	standard output. By default, `signingtool.gpg.program` is set to
> +	`gpg`.

I do not think the description is wrong per-se, but reading it made
me realize that with this "custom" program, you still require that
the "custom" program MUST accept the command line options as if it
were an implementation of GPG.  Most likely you'd write a thin
wrapper to call your custom program with whatever options that are
appropriate when asked to --verify or -bsau (aka "sign")?  If that
is the case, I have to wonder if such a wrappper program can also
trivially reformat the --- BEGIN WHATEVER --- block and behave as if
it were an implementation of GPG.  That makes the primary point of
this long series somewhat moot, as we won't need that pemtype thing
at all, no?

> +signingtool.<name>.pemtype::
> +	The PEM block type associated with the signing tool named
> +	`<name>`. For example, the block type of a GPG signature
> +	starting with `-----BEGIN PGP SIGNATURE-----` is `PGP
> +	SIGNATURE`. When verifying a signature with this PEM block type
> +	the program specified in `signingtool.<name>.program` will be
> +	used. By default `signingtool.gpg.pemtype` contains `PGP
> +	SIGNATURE` and `PGP MESSAGE`.

As Eric noted elsewhere, I suspect that it is cleaner and more
useful if this were *NOT* "pemtype" but were "boundary", i.e.
letting "-----BEGIN PGP SIGNATURE-----\n" string be specified.

> +signingtool.default::
> +	The `<name>` of the signing tool to use when creating
> +	signatures (e.g., setting it to "foo" will use use the program
> +	specified by `signingtool.foo.program`). Defaults to `gpg`.

Will there be a command line option to say "I may usually be using
whatever I configured with signingtool.default, but for this single
invocation only, let me use something else"?  Without such a command
line option that overrides such a default, I do not quite get the
point of adding this configuration variable.

Thanks.