Ben Toews <mastahyeti@xxxxxxxxx> writes: > From: Ben Toews <btoews@xxxxxxxxxx> > > 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.
