From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Rolf Eike Beer <eb@emlix.com>,
git@vger.kernel.org, Jaydeep P Das <jaydeepjd.8914@gmail.com>,
Hariom Verma <hariom18599@gmail.com>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH] gpg-interface: set trust level of missing key to "undefined"
Date: Sat, 22 Apr 2023 06:47:58 -0400 [thread overview]
Message-ID: <20230422104758.GA2969939@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqy1mnanz8.fsf@gitster.g>
On Wed, Apr 19, 2023 at 08:30:35AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Here's the patch that I came up with, though it does not distinguish
> > between "we did not see any trust level" and "gpg told us the trust
> > level was undefined". I think that's OK. That level is still below
> > TRUST_NEVER. But if we really want to distinguish we can introduce a new
> > value for the enum.
>
> Good.
>
> In my zeroth draft, I added to the enum a new TRUST_FAILED = -1 to
> be used for the initialization assignment and get stringified in the
> gpg_trust_level_to_str() function, which gave us the distinction and
> made sure the enum is signed. But in the end, I decided it was not
> worth risking upsetting the end-user scripts that assumed the
> current set of levels with a new "level" that is not known to them.
>
> Initializing to undefined like this patch is with much less damage
> to the codebase, and existing end-user scripts are probably prepared
> to react to "undefined" already and treat it as even less trustworthy
> than the "never" ones.
One thing that I wondered about for using UNDEFINED is that we do this:
static enum signature_trust_level configured_min_trust_level = TRUST_UNDEFINED;
which is then later compared with:
status |= sigc->result != 'G';
status |= sigc->trust_level < configured_min_trust_level;
So before my patch the uninitialized state is (supposedly) less than the
min level, and after they are the same. For the reasons I gave in the
commit message, I think that less-than comparison was already broken.
And likewise, for the reasons I gave, it hopefully never matters since
the result would never be 'G' in that case.
So I think it's fine, but I definitely had to stare at it for a while.
This all comes from 54887b4689 (gpg-interface: add minTrustLevel as a
configuration option, 2019-12-27), which does discuss some of the
implications, but I think my patch is in line with the logic there.
-Peff
next prev parent reply other threads:[~2023-04-22 10:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 6:12 gpg-related crash with custom formatter (BUG: gpg-interface.c:915: invalid trust level requested -1) Rolf Eike Beer
2023-04-18 6:48 ` Jeff King
2023-04-18 15:16 ` Jaydeep Das
2023-04-18 16:24 ` Junio C Hamano
2023-04-19 1:29 ` [PATCH] gpg-interface: set trust level of missing key to "undefined" Jeff King
2023-04-19 15:30 ` Junio C Hamano
2023-04-22 10:47 ` Jeff King [this message]
2023-04-24 16:22 ` Junio C Hamano
2023-04-18 16:17 ` gpg-related crash with custom formatter (BUG: gpg-interface.c:915: invalid trust level requested -1) Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230422104758.GA2969939@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=chriscool@tuxfamily.org \
--cc=eb@emlix.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hariom18599@gmail.com \
--cc=jaydeepjd.8914@gmail.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.
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).