This is an upstream report from a Kleopatra bug. You can't certify public keys
with expired subkeys (or the problem are the expired selfsigs?) with Kleopatra (
https://bugs.kde.org/show_bug.cgi?id=358392 ).
I've looked into it and the reason for this is that GnuPG sends:
[GNUPG:] KEYEXPIRED 1447544060
When starting to edit the key. QGpgME's editkeyinteractor treats this as the
error it is and aborts.
Is this the correct behavior or a bug? Should KEYEXPIRED be ignored in edit-key?
I don't think so as I would want to fail if the all UID's are expired.
To reproduce import attached key:
and run:
gpg2 --status-fd 0 --edit-key --with-colons 31A70953D8D590BA1FAB37762F3898CEDEE958CF
Output is:
gpg2 --status-fd 0 --edit-key --with-colons
31A70953D8D590BA1FAB37762F3898CEDEE958CF
gpg (GnuPG) 2.1.12-beta159; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
[GNUPG:] KEYEXPIRED 1447544060
uid Facebook, Inc.
sig!3 DEE958CF 2015-05-17 never [self-signature]*
[expires: 2018-05-17 14:39:50]
sub 96FDE3D7
sig! DEE958CF 2015-05-18 never [self-signature]*
[expires: 2015-11-13 23:00:00]
sub DA25FF20
sig! DEE958CF 2015-10-16 never [self-signature]*
[expires: 2016-01-12 23:00:00]
key DEE958CF:
1 duplicate signature removed
[GNUPG:] KEYEXPIRED 1447544060
gpg>