Mar 30 2017
Feb 22 2017
Sep 14 2016
No bug, Use "cert" and not "certify".
May 20 2016
Tracked at: https://bugs.kde.org/show_bug.cgi?id=363309
May 18 2016
May 4 2016
Thanks for the clarification. I'll ignore it in QGpgME then, too.
And after grepping for KEYEXPIRED in doc I have now found the DETAILS
documentation of which I was unaware until now. :-)
This is documented behaviour; see below. GPA ignores this status line.
- KEYEXPIRED <expire-timestamp> The key has expired. expire-timestamp is the expiration time in seconds since Epoch. This status line is not very useful because it will also be emitted for expired subkeys even if this subkey is not used. To check whether a key used to sign a message has expired, the EXPKEYSIG status line is to be used. Note, that the TIMESTAMP may either be a number of seconds since Epoch or an ISO 8601 string which can be detected by the presence of the letter 'T'.
Apr 29 2016
Note to self.
The problem is that editinteractor in edit_interactor_callback_impl checks
status_to_error before the GpgSignKeyEditInteractor::nextState implementation
has the chance to ignore that status with needsNoResponse.
A fix in GpgMEpp could be to ignore the error if the state machine was not
started. E.g. we have not yet send any command.
Attached patch fixes the problem. But I'm not sure that this does not cause
regressions e.g. when trying to add a uid to an expired key or trying to
actually sign expired uid's. :-/
Jun 8 2015
1.5.5 has been released. Closing.
Jun 5 2015
Oops. Long standing bug.
Fix in commit
Dec 11 2014
Fix has been released.
May 21 2014
Should be fixed with the current stable GnuPG and GPGME versions.
Apr 15 2014
Fixed with commit 2bb2618 for master. Will go into 1.5.0.
Apr 9 2014
May 28 2013
Duplicate of T1493
Please see T1493 - it is very likely the same reasons. I am not abale to
replicate it, though. The workaround is to configure gpgme with