Re: [PATCH] gpg-interface: still print ssh signatures when allowed signers file is not set

[Junio C Hamano <gitster@pobox.com>]

Grayson Tinker <graysontinker@gmail.com> writes:

> "show-signature" errors when the allowed signers file is not configured,
> which means that the user can't see the key that the ref was signed with
> without creating and configuring the file. Change the logic so that the file
> is only used when configured, and so the signature status is always displayed.
>
> Example of previous output:
> ```
> error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification
> commit b437db5ddc38ebda223bbae2087eee90a7b1c6e2 (HEAD -> master)
> No signature
> Author: Grayson Tinker <graysontinker@gmail.com>
> ```
>
> Example of new output:
> ```
> commit b437db5ddc38ebda223bbae2087eee90a7b1c6e2 (HEAD -> master)
> hint: Configure gpg.ssh.allowedSignersFile for automatic principal matching
> Good "git" signature with ED25519-SK key SHA256:yTU4KFs/g6MY7biDSlVStB63Gi1rCKg7dOFDXbe0yuw
> Author: Grayson Tinker <graysontinker@gmail.com>
> ```

While I haven't closely looked at the parts of this patch that I did
not quote here, this specific section caught my eye:

> @@ -528,6 +528,10 @@ static int verify_ssh_signed_buffer(struct signature_check *sigc,
>  		pipe_command(&ssh_keygen, sigc->payload, sigc->payload_len,
>  				   &ssh_keygen_out, 0, &ssh_keygen_err, 0);
>  
> +		if (!ssh_allowed_signers) {
> +			advise(_("Configure gpg.ssh.allowedSignersFile for automatic principal matching\n"));
> +		}

If a user runs 'git log --show-signature -100', they will be spammed
with this message 100 times.  Because it bypasses the
advise_if_enabled() mechanism, there is no way for them to disable
it.

Since I don't use SSH signing, I'm curious: how common or useful is
it to run log --show-signature without allowedSignersFile
configured?  If it serves no purpose at all, then perhaps this
warning is acceptable, as users would have to configure the variable
to get any utility out of the command. 

However, doesn't cryptographic verification still provide value on
its own?  Even without allowedSignersFile, the signature at least
guarantees the commit content hasn't been modified since it was
signed, even if the signer's identity remains unverified.  If some
users rely on this purely cryptographic validation, they probably
won't want to maintain an allowed signers file, and they would
definitely want a way to squelch this repetitive advice. 

Thanks.