[Bug 5649] New: gpg should handle revoked keys more gracefully

[mercurial-bugs at mercurial-scm.org]

https://bz.mercurial-scm.org/show_bug.cgi?id=5649

            Bug ID: 5649
           Summary: gpg should handle revoked keys more gracefully
           Product: Mercurial
           Version: 4.1.3
          Hardware: PC
                OS: Other
            Status: UNCONFIRMED
          Severity: feature
          Priority: wish
         Component: gpg
          Assignee: bugzilla at mercurial-scm.org
          Reporter: jeffpc at josefsipek.net
                CC: mercurial-devel at mercurial-scm.org

gpg lets you have multiple subkeys.  This lets people use a subkey for signing
commits, and a different subkey for encrypting emails, etc.  Each subkey can be
revoked.  I'm not sure if subkeys are a necessary part for this, but I suspect
they are not.

The hg gpg extension doesn't differentiate between:

(1) unsigned commit
(2) signed commit with a revoked key

For example:

$ gpg2 --gen-key 
...
$ gpg2 --edit-key test
> addkey
...
pub  2048R/B53D3C4C  created: 2017-08-07  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/AC64D35C  created: 2017-08-07  expires: never       usage: E   
sub  2048R/DDD9A222  created: 2017-08-07  expires: never       usage: S   
> save
$ hg init
$ echo test > test
$ hg add test 
$ hg commit -m "abc"
$ hg sign -u ddd9a222
signing 0:f67953b995b0
$ hg sigcheck 0
f67953b995b0 is signed by:
 test test
$ hg sigs
test test                          0:f67953b995b0f18308bc294cfdcd07b4852f7cdf
$ gpg2 --edit-key test
> key 2
> revkey
...
pub  2048R/B53D3C4C  created: 2017-08-07  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/AC64D35C  created: 2017-08-07  expires: never       usage: E   
The following key was revoked on 2017-08-07 by RSA key B53D3C4C test test
sub  2048R/DDD9A222  created: 2017-08-07  revoked: 2017-08-07  usage: S   
[ultimate] (1). test test
> save
$ hg sigcheck 0
no valid signature for f67953b995b0
$ hg sigs      
$

I am *not* a security expert, but from usability standpoint, I'd expect hg to
tell me that the signature is valid but that the (sub)key has been
revoked/expired.  Ideally, it could also print the reason the key was revoked.

Note that there are several reasons a subkey can be revoked.  gpg2 suggests:

  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used

-- 
You are receiving this mail because:
You are on the CC list for the bug.