Page MenuHome GnuPG

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


Reported in wald:

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.


External Link

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.