No key data exported by gpgme_op_export_keys()
kloecker at kde.org
Thu Apr 15 21:50:32 CEST 2021
On Donnerstag, 15. April 2021 19:28:53 CEST Dmitry Antipov via Gnupg-devel
> 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()
If you check
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
I do agree that the documentation of gpgme_op_export_keys()
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel