GpgME BUG: list expired secret keys?
marcus.brinkmann at ruhr-uni-bochum.de
Fri Apr 13 00:58:46 CEST 2007
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:
> [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 
> subkey id=9AA774B7653B2476 can_sign=0 can_encrypt=1 expired=0 expires=0
> 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:
> [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 
> subkey id=9AA774B7653B2476 can_sign=0 can_encrypt=1 expired=1 expires=0
> 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...
More information about the Gnupg-devel