[PATCH] g10: Skip signing keys where no secret key is available.

[Daniel Kahn Gillmor]

On Wed 2017-04-26 08:22:31 +0200, Patrick Brunschwig wrote:
> On 26.04.17 03:27, Daniel Kahn Gillmor wrote:
>> On Mon 2017-02-06 09:57:59 +0100, Patrick Brunschwig wrote:
>>> Would this patch still issue a "MISSING_KEY" line for --status-fd? If
>>> no, you break existing logic (which for example Enigmail relies on).
>> 
>> in what case does enigmail expect a "MISSING_KEY" line?  the scenario is
>> that the user has a primary key A and two valid, non-expired,
>> signing-capable subkeys, B and C.  C is the newer subkey, and the user
>> has specified that they want to sign with A.  We'd like to go ahead and
>> sign with B if it is available and C is missing.
>> 
>> What should enigmail do in that case with a MISSING_KEY line?  shouldn't
>> it just accept that a valid signature has been made?
>> 
>> I've pushed the proposed fix to a new git branch dkg/T1967, and updated
>> https://dev.gnupg.org/T1967 to note that branch.
>
> Sorry, I meant INV_SGNR. Enigmail looks for this when a message is
> supposed to be signed but there is no suitable key.

So you're asking whether INV_SGNR shows up in the case where there
really is *no* signing subkey, right?  because if gpg finds a different
signing subkey available and uses it successfully, you don't want it to
appear.  right?

I just did the following test in a fresh $GNUPGHOME (manually extracting
$PRIMARY_FPR and $SUBKEY0_GRIP from the relevant places), with the patch
under discussion applied here.  Note that i'm renaming
private-keys-v1.d/*.key files to emulate removal of secret key material
by any other means:


  gpg --quick-gen-key 'testing <test at example.org>' rsa cert
  gpg --quick-add-key ${PRIMARY_FPR} rsa sign # signing-capable subkey 0
  gpg --with-keygrip --list-keys
  echo test | gpg -u 'testing <test at example.org>' --status-fd=2 --clearsign
     ## makes valid signature with subkey 0, no INV_SGNR  
  mv $GNUPGHOME/private-keys-v1.d/${SUBKEY0_GRIP}{,.bak}
  echo test | gpg -u 'testing <test at example.org>' --status-fd=2 --clearsign
     ## produces INV_SGNR on stderr
  gpg --quick-add-key ${PRIMARY_FPR} rsa sign  # signing-capable subkey 1
  echo test | gpg -u 'testing <test at example.org>' --status-fd=2 --clearsign
     ## makes valid signature with subkey 1, no INV_SGNR  
  mv $GNUPGHOME/private-keys-v1.d/${SUBKEY1_GRIP}{,.bak}
  echo test | gpg -u 'testing <test at example.org>' --status-fd=2 --clearsign
     ## produces INV_SGNR on stderr
  mv $GNUPGHOME/private-keys-v1.d/${SUBKEY1_GRIP}{,.bak}
  echo test | gpg -u 'testing <test at example.org>' --status-fd=2 --clearsign
     ## makes valid signature with subkey 0, no INV_SGNR  

This seems like the sensible logic to me -- as long as some
signing-capable subkey is available.  Does enigmail need something
different?

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170426/65c9488e/attachment.sig>