Inocrrect(?) verification exit code for revoked certificates

[David Shaw]

On Feb 24, 2012, at 9:27 AM, Joanna Rutkowska wrote:

> Wile it seems to me that an error exit code should returned in this
> case. After all a "good" signature made with a compromised key, should
> not be considered as "good"...
> 
> This is especially important for build scripts that make use of gpg in
> order to verify downloaded tarballs.
> 
> A similar issue is when we one tries to verify the signature using
> untrusted key -- shouldn't gpg return an error exit code in this case as
> well?

Part of the problem here is the sheer number of cases of "the signature was mathematically correct, but you shouldn't accept it because of xxxxxx" (good signature from a revoked key, good signature from an expired key, good signature from an untrusted key, good but expired signature, etc, etc).  Because of this, an exit code isn't as useful.  Instead, GPG has a rich (and script parseable) way to express the many variants with the --status-fd option.

Look in doc/DETAILS for the exact language, but in general, status-fd outputs things like EXPSIG (good but expired signature), EXPKEYSIG (good signature from an expired key), REVKEYSIG (good signature from a revoked key), VALIDSIG (good signature), and so on.  Along with that is why GPG feels the key that issued the signature should be considered usable (or not): TRUST_FULLY, TRUST_NEVER, and so on, along with the reason (i.e. which trust model calculated it).

David