gpg vs gpgv and trustedkeys
Olliver Schinagl
oliver at schinagl.nl
Mon Feb 25 07:54:33 CET 2019
While working on a little project, I found that there seems to be some
discrepancy on how gpg and gpgv are to be used.
What I am trying to accomplish, is to generate an OS image, which
contains a public gpg key. The public is added using gpg --import and
kets added to the newly created pubkey.gpg.
However, the OS image has no need for the full blown gpg and happily
uses gpgv. However gpgv fails with the (now) well known error that it
cannot find the trustedkeys.gpg/kbx keyring/box.
The internet has some suggestions that it is needed for gpg to generate
a special keyring and import the keys into there. However the options
(no-default-keyring and/or --keyring) are not existant with the gpg
tools (on alpine and debian) (anymore, I believe gpg1 did have them in
the past?).
While gpgv still has the options, I don't think the intention was to
always having to supply a custom keyring to gpgv.
And so it appears that the default used keyring between the generator
and the validator are miss-matching.
Is this intended? If so, why? And what would be the reason for having
the two separate keyrings anyway.
For now, I have simply added a hack in that the two files are symlinked,
this atleast makes gpgv to work as a user would intend. I suppose the
alternative would be to rename the key after installation, but if that
was the intention, I don't seem to see why the option to use a different
keyring was removed from gpg to begin with.
Both my Alpine based gpg and gpgv are the same version, gpg (GnuPG) 2.1.18
P.S. Please keep me CC-ed as I am not subsribed.
More information about the Gnupg-users
mailing list