GpgME BUG: list expired secret keys?

[Marcus Brinkmann]

At Sun, 25 Feb 2007 14:50:01 +0100,
Albrecht Dreß <albrecht.dress at arcor.de> wrote:
> 
> Hi all,
> 
> I noticed a confusing behaviour of gpgme 1.1.2 when I try to list keys and  
> check their expiry status.  Running the trivial attached code (which takes  
> the second and third parameter of gpgme_op_keylist_start() as arguments),  
> I try to list an expired secret key:
> 
> <snip>
> [albrecht at antares ~]$ ./gpgme-key-expire [key_id_removed] 1
> now is 1172581963
> key: can_sign=1 can_encrypt=0 expired=0
>    subkey id=9FFF6E9CD027FFD1 can_sign=1 can_encrypt=0 expired=0  
> expires=1172493215 [1]
>    subkey id=9AA774B7653B2476 can_sign=0 can_encrypt=1 expired=0 expires=0  
> [0]
> <snip>
> 
> Although the current date is behind the expiry date of the secret sub-key  
> (can_sign=1), gpgme returns expired=0!

If you run with GPGME_DEBUG=3 or just run gpg --status-fd 2 manually,
you will probably find that this is because gpg does return incomplete
data.  As far as I understand, gnupg's key listing output of secret
keys is currently not fully complete in the manner you noticed before.
Can you confirm that this is the problem in your case?

> Running the app on the same public  
> key, the returned data looks fine, though:
> 
> <snip>
> [albrecht at antares ~]$ ./gpgme-key-expire [key_id_removed] 0
> now is 1172581965
> key: can_sign=1 can_encrypt=0 expired=1
>    subkey id=9FFF6E9CD027FFD1 can_sign=1 can_encrypt=0 expired=1  
> expires=1172493215 [1]
>    subkey id=9AA774B7653B2476 can_sign=0 can_encrypt=1 expired=1 expires=0  
> [0]
> </snip>
> 
> Did I completely misunderstand the concept of listing keys or miss some  
> "vital" initialisation here?
> 
> When I now use the "non expired" (as reported by the key list operation)  
> secret key in gpgme_op_sign() with mode GPGME_SIG_MODE_CLEAR, this  
> function returns GPG_ERR_NO_ERROR, as does gpgme_signers_add().   
> gpgme_op_sign_result() returns a valid structure, but both the  
> "signatures" and "invalid_signers" elements are NULL, so there is no way  
> to catch the real reason why the operation failed which is obviously a bad  
> situation.  Always "manually" checking the expiry date seems to be the  
> obvious workaround here, but this should be done in the library IMHO...

Thanks,
Marcus