No key data exported by gpgme_op_export_keys()

[Ingo Klöcker]

On Donnerstag, 15. April 2021 19:28:53 CEST Dmitry Antipov via Gnupg-devel 
wrote:
> On 4/15/21 7:59 PM, Ingo Klöcker wrote:
> > Are both keys in your actual public key ring?

You didn't answer my question. I bet
$ gpg -k 1D66A1789477C523
returns your key while
$ gpg -k 49FD77499570FF31
returns nothing because the Fedora key is not in your key ring.

> > My guess is that the export needs the actual key data and that's not part
> > of the result of the key list. The result of the key list only tells
> > gpgme_op_export_keys() which keys you want to export.
> 
> If so, it seems that the API is just designed to shoot yourself in the foot.

It seems that you did not fully understand what 
gpgme_op_keylist_from_data_start() (and friends) and gpgme_op_export_keys() 
do.

If you check
https://www.gnupg.org/documentation/manuals/gpgme/Key-objects.html
then you will see that the gpgme_key_t structures returned by 
gpgme_op_keylist_next() do not contain the actual public key data. Those 
structures only contain information on the keys. In particular, they contain 
their fingerprints which is then use by gpgme_op_export_keys() to know which 
keys you want to export. The actual key data to export is then read from the 
key ring.

I do agree that the documentation of gpgme_op_export_keys()
https://www.gnupg.org/documentation/manuals/gpgme/Exporting-Keys.html
is a bit misleading. I can see how "The keys to export are taken form the NULL 
terminated array keys." can be misunderstood, but it says "The keys to export 
[...]" and not "The key data to export [...]". It's like "The people to call 
are taken from the list of contacts." A contact identifies a person (more or 
less), but it certainly isn't the person.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210415/00b2dc42/attachment.sig>