Release: gnupg 1.4.1

Environment

All

Description

Gnupg could provide a better set of error codes so that "frontends" (such as enigmail) could provide better debugging information to users.
See mozdev.org bugzilla cases #7592, #9647, #9223 for specific cases where such reporting would prove invaluable.

How To Repeat

From the bugzilla site, response to RFE #9223:

The problem is this: it is possible to have a trusted key with some untrusted
UIDs. Thus, when I encrypt a message to xyz@abc, GnuPG may say "untrusted", but
if I encrypt it to the key ID, it works fine.

Furthermore, if the key ID is trusted, but the primary UID is not trusted,
Enigmail cannot detect the true trust status -- GnuPG does not tell it. Apart
from this, if a non-primary UID is not trusted you can only see it if you click
on the [+] sign.

What happens now is this: there is a new column "Trust" where the keys are
marked as "untrusted" (IF known at all).

Finally, Enigmail does not know the reason for GnuPG to refuse a receipient. The
parseable output for any invalid recipient (be it because of trust, expiry, or
whatever) is always:
[GNUPG:] INV_RECP 10 xyz@abc

Consequently, I cannot fulfil the exact desires of your request, that's why I
have just added the new trust column.

Fix

Unknown