git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Henning Schild" <henning.schild@siemens.com>,
	git@vger.kernel.org, "Eric Sunshine" <sunshine@sunshineco.com>,
	"Martin Ågren" <martin.agren@gmail.com>,
	"Ben Toews" <mastahyeti@gmail.com>,
	"Taylor Blau" <me@ttaylorr.com>,
	"brian m . carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH v2 8/9] gpg-interface: introduce new signature format "x509" using gpgsm
Date: Tue, 10 Jul 2018 10:40:22 -0700	[thread overview]
Message-ID: <xmqqbmbf7zw9.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180710170109.GG23624@sigill.intra.peff.net> (Jeff King's message of "Tue, 10 Jul 2018 13:01:10 -0400")

Jeff King <peff@peff.net> writes:

>> @@ -16,13 +16,18 @@ struct gpg_format_data {
>>  
>>  #define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
>>  #define PGP_MESSAGE "-----BEGIN PGP MESSAGE-----"
>> +#define X509_SIGNATURE "-----BEGIN SIGNED MESSAGE-----"
>>  
>> -enum gpgformats { PGP_FMT };
>> +enum gpgformats { PGP_FMT, X509_FMT };
>>  struct gpg_format_data gpg_formats[] = {
>>  	{ .format = "openpgp", .program = "gpg",
>>  	  .extra_args_verify = { "--keyid-format=long" },
>>  	  .sigs = { PGP_SIGNATURE, PGP_MESSAGE }
>>  	},
>> +	{ .format = "x509", .program = "gpgsm",
>> +	  .extra_args_verify = { NULL },
>> +	  .sigs = { X509_SIGNATURE, NULL }
>> +	},
>
> Extremely minor nit, but if there are no other uses of PGP_SIGNATURE etc
> outside of this array (as I hope there wouldn't be after this series),
> would it make more sense to just include the literals inline in the
> array definition? That's one less layer of indirection when somebody is
> reading the code.

It is good design-sense to shoot for fewer levels of indirection,
but I suspect that "'const char **' instead of maximally-sized fixed
array of strings" would require a named array and constants like
this:

	static const char *gpg_verify_args[] = {
		"--verify",
		"--status-fd=1",
		"--keyid-format=long",
		NULL
	};
	static const char *gpg_sigs[] = {
		"-----BEGIN PGP SIGNATURE-----",
		"-----BEGIN PGP MESSAGE-----",
		NULL
	};

	struct gpg_format {
		const char *name;
		const char *program;
		const char * const *verify_args;
		const char * const *sigs;
	} gpg_format[] = {
		{
			.name = "openpgp",
			.program = "gpg',
			.verify_args = gpg_verify_args,
			.sigs = gpg_sigs,
		},
		{
			...
		},
	};

so we may end up having the same number of levels of indirection
anyway in the long-term final form.

As readers may be able to read from the above, I also have a
suspicion that it is a mistake to pretend that "--verify" etc.,
which merely happen to be common across the variants the series
covers, will stay forever to be common across _all_ variants and
that is why the field no longer is called "extra" args but is meant
to contain the full args.

  reply	other threads:[~2018-07-10 18:43 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-10  8:52 [PATCH v2 0/9] X509 (gpgsm) commit signing support Henning Schild
2018-07-10  8:52 ` [PATCH v2 1/9] builtin/receive-pack: use check_signature from gpg-interface Henning Schild
2018-07-10  8:52 ` [PATCH v2 2/9] gpg-interface: make parse_gpg_output static and remove from interface header Henning Schild
2018-07-10 16:47   ` Junio C Hamano
2018-07-11  8:41     ` Henning Schild
2018-07-10  8:52 ` [PATCH v2 3/9] gpg-interface: add new config to select how to sign a commit Henning Schild
2018-07-10 15:56   ` Jeff King
2018-07-10  8:52 ` [PATCH v2 4/9] t/t7510: check the validation of the new config gpg.format Henning Schild
2018-07-10 15:55   ` Jeff King
2018-07-11  8:02     ` Henning Schild
2018-07-10 16:54   ` Junio C Hamano
2018-07-11  8:47     ` Henning Schild
2018-07-10  8:52 ` [PATCH v2 5/9] gpg-interface: introduce an abstraction for multiple gpg formats Henning Schild
2018-07-10 16:23   ` Jeff King
2018-07-13  8:41     ` Henning Schild
2018-07-10 17:16   ` Junio C Hamano
2018-07-13  8:41     ` Henning Schild
2018-07-10  8:52 ` [PATCH v2 6/9] gpg-interface: do not hardcode the key string len anymore Henning Schild
2018-07-10 15:49   ` Jeff King
2018-07-11  8:54     ` Henning Schild
2018-07-11 12:34       ` Jeff King
2018-07-11 13:46         ` Henning Schild
2018-07-11 14:27           ` Jeff King
2018-07-11 16:15             ` Henning Schild
2018-07-11 16:38               ` Jeff King
2018-07-10  8:52 ` [PATCH v2 7/9] gpg-interface: introduce new config to select per gpg format program Henning Schild
2018-07-10 16:54   ` Jeff King
2018-07-10 16:56     ` Jeff King
2018-07-14 18:13       ` brian m. carlson
2018-07-16 21:35         ` Jeff King
2018-07-16 21:56           ` Junio C Hamano
2018-07-16 22:23             ` Jeff King
2018-07-16 23:12               ` Junio C Hamano
2018-07-10 17:29     ` Junio C Hamano
2018-07-13  8:41   ` Henning Schild
2018-07-10  8:52 ` [PATCH v2 8/9] gpg-interface: introduce new signature format "x509" using gpgsm Henning Schild
2018-07-10 17:01   ` Jeff King
2018-07-10 17:40     ` Junio C Hamano [this message]
2018-07-10 17:50       ` Jeff King
2018-07-11  9:18     ` Henning Schild
2018-07-10  8:52 ` [PATCH v2 9/9] gpg-interface t: extend the existing GPG tests with GPGSM Henning Schild
2018-07-10 17:09   ` Jeff King
2018-07-10 17:16     ` Jeff King
2018-07-11 10:38     ` Henning Schild
2018-07-11 12:51       ` Jeff King
2018-07-11 13:40         ` Henning Schild
2018-07-11 14:35           ` Jeff King
2018-07-11 15:48             ` Henning Schild
2018-07-11 16:26             ` Junio C Hamano
2018-07-14 18:26       ` brian m. carlson
2018-07-10 21:12   ` Junio C Hamano
2018-07-11 10:38     ` Henning Schild
2018-07-11 14:33   ` Jeff King
2018-07-11 16:35     ` Henning Schild
2018-07-10 17:12 ` [PATCH v2 0/9] X509 (gpgsm) commit signing support Jeff King
2018-07-14 18:33   ` brian m. carlson
2018-07-16 21:32     ` Jeff King

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=xmqqbmbf7zw9.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=henning.schild@siemens.com \
    --cc=martin.agren@gmail.com \
    --cc=mastahyeti@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    --cc=sunshine@sunshineco.com \
    /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).