Page MenuHome GnuPG

Kleopatra: Changing expiry does not change expiry for subkeys
Testing, NormalPublic

Description

Reported in wald: https://wald.intevation.org/forum/message.php?msg_id=6777

Kleopatra apparently only changes the expiry on the primary key. There should be at least an option or a question to change the expiry also for subkeys.

Details

External Link
https://wald.intevation.org/forum/message.php?msg_id=6777
Version
Kleopatra-3.1.8

Event Timeline

In Kleopatra/src/dialogs/subkeyswidget.cpp there is already a context menu for subkeys.

This should now have the option to change the expiry date. Alternatively we could make the expiry editable in the list. But I don't know how to do this easily with a nice interface.

So IMO it should be OK to do a right click on the subkey. If its a secret key then offer the option to change expiry, which will then bring up a datetime picker with the current expiry date preselected. There already is an expirydialog in kleopatra.

I don't think we need the full logic of a job / command like the current expiry stuff. When the expirydialog is accepted it can start the sync call to gpgme_set_expire in the background and either show an error when finished or update the key in the subkeyswidget to reflect the changed dates.

ikloecker changed the task status from Open to Testing.Aug 12 2020, 12:30 PM
ikloecker reassigned this task from ikloecker to aheinecke.
ikloecker added a subscriber: ikloecker.

The expiry of the subkeys (and that of the primary key) can now be changed via a context menu action in the subkeyswidget.

aheinecke changed the task status from Testing to Open.Apr 12 2021, 2:40 PM
aheinecke reassigned this task from aheinecke to ikloecker.

I noticed when testing the surprising behavior that when I changed the expiry on the primary key (tested with a smartcard) it did not change the explriy on the subkey. I think in the past it must have been different that the subkey did not get the expiry by default.

We need to better handle this as kleopatra only shows the primary keys expiry and the subkeys expiry is well hidden under more details. I think its more okay to switch the logic around so that changing expiry of the primary key changed the expiry for all subkeys that have an expiry date and if you explicity change it under the more details view you can manipulate them separately.

This really depends on the use case. Some people want to extend the lifetime of their whole key. Others explicitly use a long-lived primary key with short lived subkeys. A possible heuristic for the default behavior to propose to the user would be to check whether the current expiry dates of primary key and subkeys are the same or not. The user could still change this proposed default in the dialog that's anyway shown for the new expiry date.

Yes I agree it makes sense to have this as an explicit setting to cover both use cases.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 24 2021, 9:27 AM
ikloecker changed the task status from Open to Testing.Jun 28 2021, 5:55 PM
ikloecker reassigned this task from ikloecker to aheinecke.

Fixed as discussed.

If a user changes the expiration of a key which has subkeys, then they can optionally also update the expiration of all (not revoked and not expired) subkeys. The option defaults to enabled, iff all subkeys have (more or less) the same expiration as the primary key.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 28 2021, 5:56 PM