gpg vs gpgv and trustedkeys

[Daniel Kahn Gillmor]

On Wed 2019-02-27 21:10:36 +0100, Olliver Schinagl wrote:
> During development, engineers also login to the system and may
> need to use the gpgv tool to check things. Having to point to the exact
> file is just common cause of imstakes 'where was that file again' or 'oh
> forgot'. But sure it is manageable, but.

You could write a small script or binary for your system that knows
about the specific location for the curated keyring and wraps the
invocation of gpgv.  Then encourage those engineers to use your wrapper
rather than gpgv directly.  This has the added advantage that you can
enforce additional policy (e.g. "--weak-digest sha1", or
timestamp-specific enforcement based on --status-fd, etc) in the wrapper
itself, and roll out that policy without retraining people.

> Sure, but sometimes you don't care about the precise control; just that
> it works as expected, which was my question was about.

fwiw, if you're checking cryptographic signatures, i *strongly*
recommend caring about precise control.  "works as expected" is a pretty
sloppy test -- often people will think it just means "approves
legitimately-signed files".  But for strong cryptographic verification,
you really also need to know that it "disapproves all else", right?

> Simple example; I have my keys in my keychain generated/created via gpg.
> Now I want to use gpgv to validate something, with my key, but now i
> explicitly have to point it to the pubkey, because the default of gpgv
> is trustedkey. So why the differences? Why are these not in sync, what
> is the purpose? If the reason is to force the user to use the parameter,
> why set a default, why set a default that does not match the generator.

The "trust" that gpg knows about in its keyring is "willingness to rely
on OpenPGP certifications made by the keyholder".

This is entirely orthogonal to "willingness to accept a data signature
in some specific context".

frankly, i agree with you that the existence of gpgv's default
"acceptable certificates for making data signatures" --
~/.gnupg/trustedkeys.{kbx,gpg} is a dubious feature.  If i'm checking a
signature on software package X, i care *very much* that it's not just
signed by any key i know about, but by (one of) the key(s) that is
associated with the authors of software package X.  Likewise, i'm also
checking on a new upstream release of software package Y, i *don't* want
the authors of X to have any say in the matter.

     --dkg