Improve error message for expired subkeys

[Werner Koch]

On Fri, 13 May 2016 12:06, steve at gpgtools.org said:

> occasionally we have users showing up, no longer able to encrypt their mails due to an expired subkey. The error message gnupg delivers in this case is:
>
> [GNUPG:] INV_RECP 0 Fingerprint
> [GNUPG:] FAILURE encrypt 53
>
> Basically saying, we don’t know what went wrong.

Note that INV_RECP does not give you the fingerprint but the string used
to select the key, thus it may also be a keyid, a user id, a part of a
userid, a keygrip, etc.

The error code GPG_ERR_UNUSABLE_PUBKEY (53) is given because that
reflects the actual fact: gpg was not able to use the key because
neither the primary key nor any of the subkeys are usable for
encryption.  For example because all subkeys are expired - but that is
just one case.

> Is it possible to receive a more precise error message for such cases?
> Something like
>
> [GNUPG:] INV_RECP 5 Fingerprint
> [GNUPG:] FAILURE encrypt 153
>
> That way it would be possible to display an informative error message
> including steps to solve this issue.

That does only work if you have just one subkey and for whatever reasons
that subkey expired before the primary key.  That should be a rare case.
A more common case is that there are several subkeys and none was found
to be usable.  Possibly because all are expired.  To explain this you
need more than one status message; one for each key. And then you need
to replicate the logic used by gpg to figure out which key was not
usable.  Well, we could of course emit status message during the subkey
selection process - but that can lead to a bulk of infomraiton which you
usuallay do not want.

Instead you can better list the key in question and look at the
properties direct to figure out the reason for this.  One problem here
is that you may now know which key this is (INV_RECV does not give the
fingerprint).  To solve this I can imagine a new status message
KEY_CONSIDERED to further explain the INV_RECV.

A more pragmatic solution would be to detect the case that all subkeys
are expired and then emit a new reason code.  Let me check whether this
can be easily done ...

> PS: not subscribed to list so please cc: me in replies.

[As author of one of the main GnuPG ports to OS X, you should be
subscribed.]  MUAs use the Mail-Followup-To header to decide how to
reply - because you did not set it, a group reply will send to all To
and Cc addresses.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
    /* EFH in Erkrath: https://alt-hochdahl.de/haus */