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

Description

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:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/mess
age/KUZECSCE7AF4MCFC7KSFUNJ4A6PHVAMB/

till added a subscriber: till.
justus added a subscriber: justus.Apr 1 2016, 4:18 PM

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.

justus claimed this task.Apr 1 2016, 4:18 PM
werner added a subscriber: werner.Apr 1 2016, 5:13 PM

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
object.

justus added a comment.Apr 1 2016, 5:52 PM

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

justus closed this task as Resolved.Apr 4 2016, 5:55 PM
werner added a comment.Apr 5 2016, 5:55 PM

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 reopened this task as Open.
justus removed a project: Won't Fix.
justus removed justus as the assignee of this task.May 3 2017, 10:34 AM
tmz added a subscriber: tmz.Jan 21 2018, 5:24 AM
dank added a subscriber: dank.Jan 22 2018, 4:14 PM