Page MenuHome GnuPG

Allow to inhibit the use of a default PGP keyserver
Open, NormalPublic


Often it is not desirable to use a keyserver,. However, not configuring one will fallback to a hardwired default OpenPGP keyserver. A new value "none" shall be used to disable the keyservers and have dirmngr to return GPG_ERR_NO_KEYSERVER.

Event Timeline

werner triaged this task as Normal priority.Wed, Sep 6, 9:36 AM
werner created this task.
werner created this object with edit policy "Contributor (Project)".
werner moved this task from Backlog to QA on the gnupg22 board.

Note that for vsd we also need to change our default configuration file. The new "none" value provides a better error message than the old default of assuming that the AD carries the keyserver (which it does not in practise).

BTW, with one of the recent gpgme fixes we now get

$~/b/gpgme/tests/run-keylist  --extern --verbose foo
run-keylist: file /home/wk/s/gpgme/tests/run-keylist.c line 414: <Dirmngr> No keyserver available

which is what users (and kleopatra) expects.

ebo changed the task status from Open to Testing.Thu, Sep 7, 10:50 AM
werner mentioned this in Unknown Object (Event).Mon, Sep 11, 8:45 AM
ebo changed the task status from Testing to Open.Mon, Sep 25, 1:18 PM
ebo moved this task from QA to WiP on the gnupg22 board.
ebo added projects: kleopatra, Restricted Project.
ebo added subscribers: aheinecke, ikloecker, ebo.

This works insofar that it is now possible to set "none" (via the registry in VSD):

But it does not speed up the lookup in Kleopatra as much as hoped for, yet, as we are held up by the error message "Suche auf Zertifikatserver fehlgeschlagen. Die Fehlermeldung lautet:
Kein Schlüsselserver verfügbar":

If we explicitly set "none" as a keyserver, there should be no error message because of it.

Only after acknowledging this message window do we get the WKD result.

I additionally suggest showing the WKD result first and only then showing an info window similar to the one we now show for key updates (T5903). This would fit into the scope of Ticket T6493, "Improvements on search window", though. Please consider to raise the prio of it if you want to continue this issue there.