gpg vs gpgv and trustedkeys

[Olliver Schinagl]

On 01-03-2019 07:45, Daniel Kahn Gillmor wrote:
> 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.

Well the actualy firmware image validation will be done via a script
there, so no worries on that regard. But if an engineer is tasked with
modifying any of these scripts, they may struggle to know what's going
on when invoking the tools themselves.

>
>> 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?
Oh I do agree here :)
>
>> 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.

I whole-heartedly agree now that I understand this more. As such
however, gpgv should really remove this feature all together. E.g.
always point to a keyring. The trustedkeys file is just confusing (and
the internet is only filled with confusion surounding this filename).
Many suggest to even just symlink the trustedkeys file to the pubkey files.

As there is no 'natural' way (or a suggestion in the documenation) to
create the trustedkeys file; It really probably is best to just remove
it al together.


Having said that, I'll didn't check/try; but what IS the best way to get
a key into a system. I can do gpg --import and move + package the file
of course; but is there a cleaner solution to get the file, into say
/etc/keys for example? (Without using the --keyring paramater of gpg, as
that paramater has come and gone in certain versions, so not sure how
reliable that one is). Or is it really the only and recommended way.

>
>      --dkg