Page MenuHome GnuPG
Create Task
Maniphest T4302

GPA wrongly reports failure to retrieve key
Open, NormalPublic
Actions

Description

When using the Server > Retrieve Keys... feature of GPA to fetch a remote key from a key server or a Web Key Directory, GPA reports that No keys were found. However, when asking to see the Details, one can see that GPG actually successfully imported the desired key:

[GPA 0.11.0-beta5, GPGME 1.12.1-beta113, GnuPG 2.3.0-beta562]
gpg: key F2AD85AC1E42B367: public key "[User ID not found]" imported
gpg: Total number processed: 1
gpg:               imported: 1

And when refreshing the key listing after closing the dialog, the imported key is indeed present in the keyring.

This seems independent of the actual key requested. I tested with several keys that I know are available either in a WKD or in the keyserver network, for the same result.

I initially observed this behavior with GPA 0.10.0, GnuPG 2.2.12, GpgME 1.12.0. I reproduced it with freshly built binaries from the master branch of all projects.

Details

Version
gpa-0.10.0 and gpa-0.10.0-5-g70858dc

Event Timeline

gouttegd created this task.Dec 25 2018, 3:51 PM
• werner triaged this task as Normal priority.Dec 28 2018, 6:12 PM
gouttegd added a comment.Sep 17 2022, 11:03 PM

Finally had some time to look into this a bit more.

If I understand correctly, the problem is that the search_keys function in src/gpaimportserverop.c is written using GpgME’s “normal” API (gpgme_op_keylist_start, gpgme_op_keylist_next, gpgme_op_keylist_end), but is using a GpgME context that has been set up to use the callback API. Therefore, when gpgme_op_keylist_next is called, it immediately returns EOF, and the calling code assumes that no keys were found.

A crude workaround would be to forcefully disable the callback interface for the context used in the search_keys function (“reverting” what is done in the gpa_context_new() constructor):

context = gpa_context_new();
context->io_cbs->add = NULL;
gpgme_set_io_cbs(context->ctx, context->io_cbs);