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

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

Fixed in abb352d.

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.