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