From: Henning Schild <henning.schild@siemens.com>
To: "Martin Ågren" <martin.agren@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Ben Toews <mastahyeti@gmail.com>, Jeff King <peff@peff.net>,
Junio C Hamano <gitster@pobox.com>, Taylor Blau <me@ttaylorr.com>,
"brian m . carlson" <sandals@crustytoothpaste.net>,
"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats
Date: Thu, 5 Jul 2018 15:21:58 +0200 [thread overview]
Message-ID: <20180705152158.6f661c85@md1pvb1c.ad001.siemens.net> (raw)
In-Reply-To: <CAN0heSrXpLCDRjnZC80QXBG27gd6m5reBn1hfNd_KXxnPVkA2g@mail.gmail.com>
Am Wed, 4 Jul 2018 09:10:17 +0200
schrieb Martin Ågren <martin.agren@gmail.com>:
> Hi Henning,
>
> On 3 July 2018 at 14:38, Henning Schild <henning.schild@siemens.com>
> wrote:
> > Create a struct that holds the format details for the supported
> > formats. At the moment that is still just "PGP". This commit
> > prepares for the introduction of more formats, that might use other
> > programs and match other signatures.
> >
> > Signed-off-by: Henning Schild <henning.schild@siemens.com>
>
> Welcome to the mailing list! :-)
Thanks!
> I'll just comment on a few thoughts I had while skimming this.
>
> > static char *configured_signing_key;
> > -static const char *gpg_format = "PGP";
> > -static const char *gpg_program = "gpg";
> > +struct gpg_format_data {
> > + const char *format;
> > + const char *program;
> > + const char *extra_args_verify[1];
> > + const char *sigs[2];
> > +};
> >
> > #define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
> > #define PGP_MESSAGE "-----BEGIN PGP MESSAGE-----"
> >
> > +enum gpgformats { PGP_FMT };
> > +struct gpg_format_data gpg_formats[] = {
> > + { .format = "PGP", .program = "gpg",
> > + .extra_args_verify = { "--keyid-format=long", },
> > + .sigs = { PGP_SIGNATURE, PGP_MESSAGE, },
> > + },
> > +};
>
> I think those trailing commas are ok now, but I'm not sure...
>
> I had the same thought about designated initializers. Those should be
> ok now, c.f. cbc0f81d96 (strbuf: use designated initializers in
> STRBUF_INIT, 2017-07-10) and a73b3680c4 (Add and use generic name->id
> mapping code for color slot parsing, 2018-05-26).
Ok, i did not actually check coding style yet. I could run it through a
tool, given there is a suggestion. Or i could address issues someone
points out in the review.
What i get from your comment is that it might be ok to leave the code
as is, others have introduces similar constructs before me.
> > +static const char *gpg_format = "PGP";
> > +
> > +static struct gpg_format_data *get_format_data(void)
> > +{
> > + int i;
> > + for (i = 0; i < ARRAY_SIZE(gpg_formats); i++)
> > + if (!strcmp(gpg_formats[i].format, gpg_format))
> > + return gpg_formats + i;
> > + assert(0);
>
> This might be better written as `BUG("bad gpg_format '%s'",
> gpg_format);` or something like that.
>
> (It's not supposed to be triggered, not even by invalid data from the
> user, right?)
Yes that is code that can not (should not) be reached. I agree that an
assert(0) is not very expressive and will fix that in v2.
>
> > if (!strcmp(var, "gpg.format")) {
> > - if (!strcmp(value, "PGP"))
>
> This line was added in patch 3. It errors out precisely when
> gpg.format is "PGP", no? That this doesn't break the whole series is
> explained by 1) it being removed in this patch 4, and 2) there being
> no tests. It makes me wonder if something like patch 5 (test
> gpg.format) could be part of patch 3, both with negative ("=
> malformed") and positive ("= PGP") tests?
I will pull the tests from patch 5 before touching that code and fix up
issues inbetween. The whole series saw a "make test" inbetween all
commits.
> > + j = 0;
> > + for (i = 0; i < ARRAY_SIZE(gpg_formats); i++)
> > + if (!strcmp(value, gpg_formats[i].format)) {
> > + j++;
> > + break;
> > + }
> > + if (!j)
> > return error("malformed value for %s: %s",
> > var, value);
>
> `if (i == ARRAY_SIZE(gpg_formats))` and drop `j`?
>
> Or check whether `get_format_data()` returns NULL? Hmm, well you
> can't, since it takes its "input" from a global variable...
>
> If you want to keep that global nature, the duplication of
> search-logic could perhaps be avoided by having a helper function for
> returning the index of a gpg_format (or -1).
True, the two are almost the same and should be merged. Will do in v2.
Henning
> > return git_config_string(&gpg_format, var, value);
> > }
>
> Martin
next prev parent reply other threads:[~2018-07-05 13:22 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-03 12:38 [PATCH 0/8] X509 (gpgsm) commit signing support Henning Schild
2018-07-03 12:38 ` [PATCH 1/8] builtin/receive-pack: use check_signature from gpg-interface Henning Schild
2018-07-06 19:51 ` Junio C Hamano
2018-07-06 21:35 ` Junio C Hamano
2018-07-09 8:18 ` Henning Schild
2018-07-09 15:55 ` Junio C Hamano
2018-07-03 12:38 ` [PATCH 2/8] gpg-interface: make parse_gpg_output static and remove from interface header Henning Schild
2018-07-03 12:38 ` [PATCH 3/8] gpg-interface: add new config to select how to sign a commit Henning Schild
2018-07-06 1:01 ` brian m. carlson
2018-07-06 8:02 ` Henning Schild
2018-07-06 19:58 ` Junio C Hamano
2018-07-03 12:38 ` [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats Henning Schild
2018-07-04 7:10 ` Martin Ågren
2018-07-05 13:21 ` Henning Schild [this message]
2018-07-06 17:24 ` Junio C Hamano
2018-07-09 8:21 ` Henning Schild
2018-07-09 8:44 ` Eric Sunshine
2018-07-09 15:47 ` Junio C Hamano
2018-07-10 15:37 ` Jeff King
2018-07-10 15:51 ` Junio C Hamano
2018-07-10 15:58 ` Junio C Hamano
2018-07-10 17:15 ` Jeff King
2018-07-03 12:38 ` [PATCH 5/8] t/t7510: check the validation of the new config gpg.format Henning Schild
2018-07-06 20:21 ` Junio C Hamano
2018-07-09 8:27 ` Henning Schild
2018-07-03 12:38 ` [PATCH 6/8] gpg-interface: do not hardcode the key string len anymore Henning Schild
2018-07-06 20:22 ` Junio C Hamano
2018-07-03 12:38 ` [PATCH 7/8] gpg-interface: introduce new signature format "X509" using gpgsm Henning Schild
2018-07-06 1:10 ` brian m. carlson
2018-07-06 8:01 ` Henning Schild
2018-07-06 20:34 ` Junio C Hamano
2018-07-03 12:38 ` [PATCH 8/8] gpg-interface t: extend the existing GPG tests with GPGSM Henning Schild
2018-07-06 1:14 ` brian m. carlson
2018-07-06 8:01 ` Henning Schild
2018-07-06 1:18 ` [PATCH 0/8] X509 (gpgsm) commit signing support brian m. carlson
2018-07-06 8:01 ` Henning Schild
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=20180705152158.6f661c85@md1pvb1c.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).