Page MenuHome GnuPG

gpgme: gpgme_op_receive_keys does not return an error if keyserver lookup is disabled
Testing, NormalPublic


gpgme_op_receive_keys does not return an error if keyserver lookup is disabled. It seems that the FAILURE status message is ignored.

How to reproduce:

  • Set keyserver to none in dirmngr.conf
  • Run gpgme/tests/run-receive-keys 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1

Expected result: The command exists with an error message.
Actual result: The command prints an (empty) import result.

Similarly, gpgme/lang/qt/tests/run-receivekeysjob 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1 shows

Result: Success

Event Timeline

ikloecker triaged this task as Normal priority.Mar 11 2024, 11:34 AM
ikloecker created this task.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ikloecker changed the task status from Open to Testing.Mar 11 2024, 3:45 PM

This can be tested with Kleopatra by configuring an invalid keyserver and then updating an OpenPGP certificate.

Tested with VS-Desktop-

I get "Update skipped because no OpenPGP keyserver is configured" in Kleopatra when I set keyserver to "none", I guess this means I should close this ticket.

But any other misconfiguration results in "certificate has not changed". Either immediately or - if you have no network connection - after the timeout.

I guess I have to make a new ticket for that (or even two?)
Would that be a gpgme ticket and a companion Kleopatra ticket again? Or does a "unkown server" or a "network not available" error require some other approach?

In T7036#186290, @ebo wrote:

Tested with VS-Desktop-

We figured out that this build doesn't include the fix. It uses the latest release of gpgme from November 2023.