Page MenuHome GnuPG

--locate-key should re-fetch key via WKD if it is expired
Closed, ResolvedPublic


If one tries to fetch a key over wkd and there already is an earlier expired
version of that key in the local keyring gnupg doesn't re-fetch the key. This
doesn't seem to make sense, because it'll mean an expired key can never be
updated over wkd.

To reproduce:

  • Import attached key, which is expired (a new version is provided over wkd).
  • Try to import:

gpg --auto-key-locate=wkd --locate-key [emailaddress]

It'll just show the expired key.



Event Timeline

hanno set Version to 2.1.17.
hanno added a subscriber: hanno.

For what it's worth i think WKD checks should be done even more regularly then
when they are explicitly triggered thorugh locate keys because we need to see
updates on key rollover / revocation of keys or uids. Something like the
parcimonie style auto-key-refesh that is currently planned.

But yes re fetching on locate-keys if the key / uid for key-locate is expired
would be a first step.

justus changed Version from 2.1.17 to master.Mar 2 2017, 3:28 PM
justus added a subscriber: justus.

Hum, there is something strange going on here:

% gpg --auto-key-locate wkd --locate-key root@leckerlecker
... no update...
% gpg --auto-key-locate wkd,local --locate-key root@leckerlecker
... no update...
% gpg --auto-key-locate clear,wkd,local --locate-key root@leckerlecker
... update!...

So I went over the code that does --locate-key. There, the available methods
are ordered, and if 'local' is not given, it is explicitly done first, unless
'nodefault' is given. This is one of the parts of GnuPG that I'm really afraid
to change ;)

That implicit local is for backward compatibility and to avoid network lookups
as much as possible (privacy leak). "clear" is required because auto-key-locate
is cumulative.

Yes, I think that would be good.

werner raised the priority of this task from Normal to High.Jul 2 2018, 10:39 AM

Maybe a first step would be a "KEYLIST_MODE_WKD" which sets "auto-key-locate clear,nodefault,wkd" (Would be nice for T3910 ) or just a ctx_flag "auto-key-locate" so that the caller can decide?

Actually the --locate-key command differs from the implicit use of locate key code when encrypting to a mail address.
After importing the expired key and running for example

fortune | ~/b/gnupg-2.2/g10/gpg --always-trust --no-encrypt-to -vaer  THATMAILADDRESS

The expired key is detected and a fresh copy is retrieved via WKD.

werner renamed this task from wkd discovery should re-fetch key if it is expired to --locate-key should re-fetch key via WKD if it is expired.Jul 6 2018, 9:09 AM
werner updated the task description. (Show Details)
werner removed a project: gnupg (gpg22).
werner edited projects, added gnupg (gpg22); removed gnupg.

Done. To be released with 2.2.10.

FWIW: We check for an expired primary key and for expired encryption subkeys but not for other subkeys like authentication subkeys.

Why the restriction to keyorg wkd ?

In my opinion "--locate-key" should behave like no local key was found if the only local key found is expired. And then use the auto-key-locate options as configured.

From a MUA standpoint the case "We only find an expired key" and "We do not find any key" are basically the same.

The problem for me is that I have very few keys with origin wkd initially in an existing key ring. And even for new keyrings WKD will not be set as origin for all the keys fetched through auto-key-retrieve and other sources even though it may additionally be available in WKD.

Without KEYLIST_MODE_WKD I also can't implement the desired behavior in a MUA using GnuPG.