Page MenuHome GnuPG

Allow gpgv2 to use armored GPG keys as keyring file with trusted keys
Open, WishlistPublic


gpgv2 requires the --keyring parameter to specify binary GPG keys/a keyring. It
would be more convinient if it was possible to just use ASCII-armored keys as
well. This would be nice for the Fedora project to easily verify GPG signatures
of upstream projects without storing binary files in GIT:

Event Timeline

It is not trivial, but I guess we could create a temporary keyring and import
the key. But to be honest I don't understand why storing base64-encoded random
junk is somehow better than storing the junk itself, I mean it wont diff better
or something.

I can understand the reason to avoid binary data in a repo.

I have not checked but iff we use estream to access a plain old keyring it would
be possible to use the existing unarmor code and feed that to an es_fopenmem

Ok, if you agree that this is a useful feature then I will implement it.

Although the patch is not very intrusive to other parts of GnuPG,
I do not like it for several reasons:

  • Armored is detected by the file's suffix. That is not the Unix way.
  • open and close is used - we should avoid that in new code. Always use es_ functions for better portability.
  • There is new function to create some temp dir despite that we already have such functions elsewhere. I have not seen the immediate reason for it.

My suggestion was to read the file into an estream object and change
the dearmor and keydb_add_resources to be able to work with it. There
is a unarmor_pump_new function which could be a starting point.
Granted, this would be a much more intrusive change and thus I doubt
that it is useful to spend too resources on it.

Can you please back out that commit.

BTW, please do not put a "cleanup" label in the mid of a function and
according to GNU standards initialized variables deserve separate
lines and statements.

werner lowered the priority of this task from Normal to Wishlist.Feb 10 2021, 11:02 AM