git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] ref-filter: add new atom "signature" atom

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 27, 2022, 02:20 UTC
Message-ID
<xmqqo7rpvb83.fsf@gitster.g>
In-Reply-To
<pull.1452.git.1672102523902.gitgitgadget@gmail.com>
"nsengaw4c via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 7 quoted lines
> From: Nsengiyumva Wilberforce <nsengiyumvawilberforce@gmail.com>
>
> This only works for commits. Add "signature" atom with `grade`,
> `signer`, `key`, `fingerprint`, `primarykeyfingerprint`, `trustlevel`
> as arguments. This code and it's documentation are inspired by
> how the %GG, %G?, %GS, %GK, %GF, %GP, and %GT pretty formats were
> implemented.

Lacking motivation. Without explaining why somebody may want to have the feature and what it would be used for, "only works for commits" would invite a "so what? does it even have to work?" as a response, so start with a brief descrioption "with the current set of atoms, $this_useful_thing cannot easily be achieved" before describing its limitation.

Having said that, wouldn't it be natural to expect that the same code can deal with signed tags? After all we use the same signature verification machinery at the lowest level in the callchain.

Show 13 quoted lines
> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index 6da899c6296..9a0be85368b 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -212,6 +212,33 @@ symref::
>  	`:lstrip` and `:rstrip` options in the same way as `refname`
>  	above.
>  
> +signature::
> +...
> +signature:trustlevel::
> +	The Trust level of the GPG signature of a commit. Possible
> +	outputs are `ultimate`, `fully`, `marginal`, `never` and `undefined`.

A good list. How do these work for signature made with a tool other than GPG (in other words, when "gpg.format" is set to something other than "openpgp")?

Show 27 quoted lines
> @@ -378,6 +383,30 @@ static int subject_atom_parser(struct ref_format *format, struct used_atom *atom
>  	return 0;
>  }
>  
> +static int signature_atom_parser(struct ref_format *format, struct used_atom *atom,
> +			       const char *arg, struct strbuf *err)
> +{
> +	if (arg) {
> +		if (!strcmp(arg, "signer"))
> +			atom->u.signature.option = S_SIGNER;
> +		else if (!strcmp(arg, "grade"))
> +			atom->u.signature.option = S_GRADE;
> +		else if (!strcmp(arg, "key"))
> +			atom->u.signature.option = S_KEY;
> +		else if (!strcmp(arg, "fingerprint"))
> +			atom->u.signature.option = S_FINGERPRINT;
> +		else if (!strcmp(arg, "primarykeyfingerprint"))
> +			atom->u.signature.option = S_PRI_KEY_FP;
> +		else if (!strcmp(arg, "trustlevel"))
> +			atom->u.signature.option = S_TRUST_LEVEL;
> +		else
> +			return strbuf_addf_ret(err, -1, _("unknown %%(signature) argument: %s"), arg);
> +	}
> +	else
> +		atom->u.signature.option = S_BARE;
> +	return 0;
> +}

Handing the !arg case first will make the if/else if/... cascade easier to follow, no? Also the body of the function may want to become a separate function that returns one of these S_FOO constants.

	static enum signatore_option signature_atom_parser(...)
	{
                enum signature_option opt = parse_signature_option(arg);
                if (opt < 0)
                        return strbuf_addf_ret(err, opt, _("unknown ..."), arg);
                return opt;
	}
where parse_signature_option() would look like
	static enum signature_option parse_signature_option(const char *arg)
	{
		if (!arg)
			return S_BARE;
		else if (!strcmp(arg, "signer"))
			return S_SIGNER;
		...
		else
			return -1;
	}
or something like that?
Show 5 quoted lines
> @@ -1344,6 +1374,69 @@ static void grab_person(const char *who, struct atom_value *val, int deref, void
>  	}
>  }
>  
> +static void grab_signature(struct atom_value *val, int deref, struct object *obj)

To be considerate for future developers, perhaps rename this to grab_commit_signature(), so that they can add grab_tag_signature() when they lift the limitation of this implementaiton?

> +{
> +	int i;
> +	struct commit *commit = (struct commit *) obj;
Style?  No SP between cast and value?
Show 19 quoted lines
> +
> +	for (i = 0; i < used_atom_cnt; i++) {
> +		struct used_atom *atom = &used_atom[i];
> +		const char *name = atom->name;
> +		struct atom_value *v = &val[i];
> +		struct signature_check sigc = { 0 };
> +
> +		if (!!deref != (*name == '*'))
> +			continue;
> +		if (deref)
> +			name++;
> +		if (strcmp(name, "signature") &&
> +			strcmp(name, "signature:signer") &&
> +			strcmp(name, "signature:grade") &&
> +			strcmp(name, "signature:key") &&
> +			strcmp(name, "signature:fingerprint") &&
> +			strcmp(name, "signature:primarykeyfingerprint") &&
> +			strcmp(name, "signature:trustlevel"))
> +			continue;

And with the helper above, we can avoid the repetition here that can go out of sync with the parser function.

> +		check_commit_signature(commit, &sigc);

If a format asks for signature:signer and signature:key, we shouldn't be running GPG twice. First check used_atom[] to see if we even need to do _any_ signature processing (and leave if there is not), populate the sigc just once and then enter the loop, perhaps?

In adddition, a call to check_commit_signature() should have a matching call to signature_check_clear(); otherwise all the resources held by sigc would leak, wouldn't it?

Previous: nsengaw4c via GitGitGadgetNext: NSENGIYUMVA WILBERFORCE
Message 2 of 19 in “ref-filter: add new atom "signature" atom”
  1. ref-filter: add new atom "signature" atomnsengaw4c via GitGitGadget, Dec 27, 2022
  2. Junio C HamanoDec 27, 2022
  3. NSENGIYUMVA WILBERFORCEJan 2, 2023
  4. Christian CouderJan 2, 2023
  5. Junio C HamanoJan 3, 2023
  6. Jeff KingDec 27, 2022
  7. NSENGIYUMVA WILBERFORCEJan 2, 2023
  8. 0/1 ref-filter: add new "signature" atomNsengiyumva Wilberforce, Jan 10, 2023
  9. 1/1 ref-filter: add new "signature" atomNsengiyumva Wilberforce, Jan 10, 2023
  10. 0/1 ref-filter: add new "signature" atomNsengiyumva Wilberforce, Jan 16, 2023
  11. 1/1 ref-filter: add new "signature" atomNsengiyumva Wilberforce, Jan 16, 2023
  12. 0/1 ref-filter: add new "signature" atomNsengiyumva Wilberforce, Mar 11, 2023
  13. 1/1 ref-filter: add new "signature" atomNsengiyumva Wilberforce, Mar 11, 2023
  14. Junio C HamanoMar 14, 2023
  15. Kousik SanagavarapuApr 28, 2023
  16. Kousik SanagavarapuApr 29, 2023
  17. Junio C HamanoJan 26, 2023
  18. Christian CouderJan 10, 2023
  19. NSENGIYUMVA WILBERFORCEJan 8, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.