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

[Patrick Brunschwig]

On 27.04.17 04:02, Daniel Kahn Gillmor wrote:
> 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?

Perfect - that's exactly what Enigmail would expect.

Thanks,
Patrick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170427/b6484741/attachment.sig>