Concept ACK. Regarding the lint failure about not quoting the new variable, I am unsure whether this lint failure is actually a problem. It seems to me that some users may wish to pass extra arguments to whatever executable is used in place of gpg; quoting the variable would prevent this use case. Thoughts?

It seems to me that some users may wish to pass extra arguments to whatever executable is used in place of gpg; quoting the variable would prevent this use case.

If we want to enable passing the extra arguments, we'd need to do the following change, so the check_tools correctly extracts the binary name and checks against that.

- check_tools ${GPG}
+ GPG_ARRAY=($GPG)
+ check_tools "${GPG_ARRAY[0]}"

If we want to disable passing the extra arguments, it's enough to just quote the variable usage, right.

I will wait for resolution which way we want to go and then I'll update the PR.

I have a weak preference for allowing extra arguments, but I do not have any immediate need for it myself, so will defer if anyone else has a good reason not to.

I have a weak preference for allowing extra arguments

Applied the improvement from #24552 (comment) in e368c03

If there is a consensus we do not want $GPG to contain extra arguments, I will gladly rework the PR

Concept ACK

Concept and code review ACK af74e06

I think passing extra arguments to gpg is a valid usecase. Though, as of course always with shell nonsense, this interferes with using spaces in filenames. But that's probably not too common (sigh)…