Page MenuHome GnuPG
Create Task
Maniphest T2339

Edit-key with-colons reports KEYEXPIRED on status-fd if one subkey (or selfsig?) is expired
Closed, ResolvedPublic
Actions

Description

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>

Details

External Link
https://bugs.kde.org/show_bug.cgi?id=358392
Version
master

Related Objects

Event Timeline

• aheinecke set Version to master.Apr 29 2016, 4:48 PM
• aheinecke added projects: KDE, gnupg, Bug Report.
• aheinecke added a subscriber: • aheinecke.

824_facebook.asc204 KBDownload

• aheinecke set External Link to https://bugs.kde.org/show_bug.cgi?id=358392.Apr 29 2016, 4:48 PM
• aheinecke added a comment.Apr 29 2016, 6:45 PM

D366: 825_fix-in-gpgmepp.patch

• aheinecke added a comment.Apr 29 2016, 6:45 PM

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. :-/

• werner added a subscriber: • werner.May 4 2016, 9:31 AM

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'.
• aheinecke added a comment.May 4 2016, 9:38 AM

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. :-)

• aheinecke closed this task as Resolved.May 4 2016, 9:38 AM
• aheinecke claimed this task.