Incorrect GPG signature status if (sub)key was revoked

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Summary

Currently there are only two statuses -- verified or unverified -- for GPG/PGP signatures, and sometimes they're not a correct reflection of the validity of signatures.

For example, if a commit is signed by a valid subkey, but later that subkey got revoked (or expires? didn't test), after uploading the public key again, the commit is then labelled with 'unverified'. But unless the signature is generated after the subkey's been revoked, IMO it should still be considered 'verified'. Perhaps we can also take the 'revocation reason' into consideration: if it was 'compromised' then sure, label those commits as 'unverified', since we don't know when exactly it was compromised; but if it's simply 'no longer being used', I think the existing commits/annotated tags/etc should still stay verified.

Actually from man git-log we can see:

%G?
   show "G" for a good (valid) signature, "B" for a bad signature, "U" for a
   good signature with unknown validity, "X" for a good signature that has
   expired, "Y" for a good signature made by an expired key, "R" for a good
   signature made by a revoked key, "E" if the signature cannot be checked
   (e.g. missing key) and "N" for no signature

For now I think if we can rewire the signature info -> verified/unverified mapping, it'd be great; but in the long run I believe having a few more badges is the way to go.