git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Ben Toews <mastahyeti@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>, Taylor Blau <me@ttaylorr.com>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH 8/8] gpg-interface: handle alternative signature types
Date: Tue, 10 Apr 2018 10:01:36 -0600	[thread overview]
Message-ID: <CAE=pOyHey_8kJ0JsA3ROhpE9qn+HivVQgwd+Wdonw8L6D+9MUg@mail.gmail.com> (raw)
In-Reply-To: <xmqqr2nn2ylz.fsf@gitster-ct.c.googlers.com>

On Tue, Apr 10, 2018 at 3:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 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?
>

Just because a signature is PEM encoded and claims to be a "PGP
SIGNATURE", doesn't mean it can be understood or verified by a PGP
implementation. Without different tools specifying different PEM types
we would have no way of knowing which tool to route the signature to
for verification.

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



-- 
-Ben Toews

  reply	other threads:[~2018-04-10 16:02 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09 20:41 [PATCH 0/8] gpg-interface: Multiple signing tools Ben Toews
2018-04-09 20:41 ` [PATCH 1/8] gpg-interface: handle bool user.signingkey Ben Toews
2018-04-09 20:55   ` Eric Sunshine
2018-04-10 14:32     ` Jeff King
2018-04-09 20:41 ` [PATCH 2/8] gpg-interface: modernize function declarations Ben Toews
2018-04-09 20:41 ` [PATCH 3/8] gpg-interface: use size_t for signature buffer size Ben Toews
2018-04-09 20:41 ` [PATCH 4/8] gpg-interface: fix const-correctness of "eol" pointer Ben Toews
2018-04-09 20:41 ` [PATCH 5/8] gpg-interface: extract gpg line matching helper Ben Toews
2018-04-09 20:41 ` [PATCH 6/8] gpg-interface: find the last gpg signature line Ben Toews
2018-04-09 21:13   ` Eric Sunshine
2018-04-10  9:44   ` Junio C Hamano
2018-04-10 14:47     ` Ben Toews
2018-04-10 21:04       ` Junio C Hamano
2018-04-10 22:17         ` Junio C Hamano
2018-04-11 15:19           ` Ben Toews
2018-04-09 20:41 ` [PATCH 7/8] gpg-interface: prepare for parsing arbitrary PEM blocks Ben Toews
2018-04-09 20:41 ` [PATCH 8/8] gpg-interface: handle alternative signature types Ben Toews
2018-04-09 21:01   ` Stefan Beller
2018-04-10  8:24   ` Eric Sunshine
2018-04-10 15:00     ` Ben Toews
2018-04-14 19:59     ` brian m. carlson
2018-04-16  5:05       ` Junio C Hamano
2018-04-17  0:12         ` brian m. carlson
2018-04-17  1:54           ` Junio C Hamano
2018-04-17 18:08             ` Ben Toews
2018-04-17 18:33               ` Taylor Blau
2018-05-03 16:03                 ` Ben Toews
2018-05-07  9:45           ` Jeff King
2018-05-07 15:18             ` Junio C Hamano
2018-05-07 23:06             ` brian m. carlson
2018-05-08 13:28               ` Jeff King
2018-05-08 23:09                 ` brian m. carlson
2018-05-09  8:03                   ` Jeff King
2018-04-10  9:35   ` Junio C Hamano
2018-04-10 16:01     ` Ben Toews [this message]
2018-04-11 10:11   ` SZEDER Gábor
2018-04-13 21:18 ` [PATCH v2 0/9] gpg-interface: Multiple signing tools Ben Toews
2018-04-13 21:18 ` [PATCH v2 1/9] t7004: fix mistaken tag name Ben Toews
2018-04-13 21:18 ` [PATCH v2 2/9] gpg-interface: handle bool user.signingkey Ben Toews
2018-04-13 21:18 ` [PATCH v2 3/9] gpg-interface: modernize function declarations Ben Toews
2018-04-13 21:18 ` [PATCH v2 4/9] gpg-interface: use size_t for signature buffer size Ben Toews
2018-04-13 21:18 ` [PATCH v2 5/9] gpg-interface: fix const-correctness of "eol" pointer Ben Toews
2018-04-13 21:18 ` [PATCH v2 6/9] gpg-interface: extract gpg line matching helper Ben Toews
2018-04-13 21:18 ` [PATCH v2 7/9] gpg-interface: find the last gpg signature line Ben Toews
2018-04-13 21:18 ` [PATCH v2 8/9] gpg-interface: prepare for parsing arbitrary PEM blocks Ben Toews
2018-04-13 21:18 ` [PATCH v2 9/9] gpg-interface: handle alternative signature types Ben Toews

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAE=pOyHey_8kJ0JsA3ROhpE9qn+HivVQgwd+Wdonw8L6D+9MUg@mail.gmail.com' \
    --to=mastahyeti@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).