gpgme should allow refreshing OpenPGP keys via the external methods as defined by the auto-key-locate option and from the configured keyserver, i.e. a combination of --locate-external-keys and --refresh-keys (or --recv-keys).
Description
Description
Revisions and Commits
Revisions and Commits
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Testing | None | T5903 Kleopatra: Add refresh button in certificatedetails and an auto refresh | ||
| Testing | None | T5951 gpgme: Add support for refreshing OpenPGP keys |
Event Timeline
Comment Actions
I am reopening this as the current behavior is strange in my opinion and should be changed before a release.
Currently the refreshopenpgpkeysjob does not refresh the OpenPGP Key by fingerprint but instead imports all keys with a similar e-mail address. This does not work for keys with no email. Also in case of public keyservers it can pull in keys that not belong to the user or are expired and so on.
This is very unexpected when used from Kleopatra and "Update" imports additional keys. At first I thought the additonal keys were imported because they had certified the key but when looking at the code i saw that it searched by email and not by fingerprint. What is the reason for this, or the intended use case?
Comment Actions
The lookup by email address is supposed to be done via WKD. Obviously, a lookup by fingerprint wouldn't work. And yes, obviously this may import additional key via WKD.
For the key server refresh the fingerprint should be used. But maybe I made a mistake.
Comment Actions
Okay. I do a KeyListJob with key list mode GpgME::LocateExternal which does the equivalent of --locate-external-keys and that depends on the auto-key-locate mechanisms which could include keyserver and other mechanisms besides WKD.
I could argue that people who have keyserver in their auto-key-locate list are okay with retrieving additional keys for email addresses. I mean they will fetch a "random" key matching the email address when they want to encrypt something for this email address. But, yes, they probably wouldn't expect this if they do an update.
I could add a special key list mode GpgME::WKD which would use --locate-external-keys with --auto-key-locate clear,wkd. Or shall I remove the update via WKD? Then, how would one update a key via WKD?
Comment Actions
I thought "Update" would do a key server refresh by fingerprint. Maybe I looked at the wrong job? In testing we noticed this because we suddenly had additional keys after using "update". "Update" in the certificate details should only search by fingerprint. Maybe when we know that the key source is WKD we could also look by mail address?
Comment Actions
See T5903: Kleopatra: Add refresh button in certificatedetails and an auto refresh for the corresponding Kleopatra task. Kleopatra now uses the good old ReceiveKeysJob for doing a key refresh from the configured key server. The RefreshOpenPGPKeysJob has been removed.
The changes in gpgme are binary compatible to the latest released version of gpgme, but they are binary incompatible with previous intermediate snapshots.
Comment Actions
Thanks, the update button this is now more what I think is expected. Still I am not sure if removing it completely was neccessary, well we have it in the history now. Because I see the need to also update via WKD. Currently we only update from there if a key is expired but we would never see revocations. That is a problem that we will need some solution for at some point. But yeah in that case calling it "RefreshOpenPGPKeysJob" would be a misleading API Name anyhow. So its probably good that you removed it before the upcoming release.
Comment Actions
I have kept a backup copy of a WKDRefreshJob locally. ;-) But that's stuff for a different task.