Page MenuHome GnuPG

Kleopatra: "Change Validity" sometimes ignores subkey when extending validity
Testing, NormalPublic


This is similar to T6473 but it occurs only in certain circumstances.

I managed to reproduce on Windows (using the Ted key from out testset) by preparing an expired key in the following way. It seems it is important that the subkey expires first and that Kleopatra notices this, that's why I use "gpg -K" here.

gpg --quick-set-expire 98111E67AE06F2BEFD2BDE10C5D6C919005F36A4 seconds=10 CC5274CB8072E9778DADD15BCD573B2B0736643A
gpg -K 98111E67AE06F2BEFD2BDE10C5D6C919005F36A4
gpg --quick-set-expire 98111E67AE06F2BEFD2BDE10C5D6C919005F36A4 seconds=10

A sure sign that the prolongation of the subkey will not occur is that the checkbox for "Also update the validity period of the subkeys" is not already checked and has to be activated manually.

The attached gpgme log only covers trying to extend a key prepared like that via right-click.



Event Timeline

ebo triaged this task as Normal priority.Jan 24 2024, 2:55 PM
ebo created this task.

Kleopatra behaves as intended (by me). Only subkeys meeting the following conditions are extended together with the primary key:

  • skip revoked subkeys which would anyway be ignored by gpg;
  • also skip subkeys without explicit expiration because they inherit the primary key's expiration;
  • include all subkeys that are not yet expired or that expired around the same time as the primary key

The reasoning for the third condition is that "long" expired (encryption) subkeys should not be revived if the primary key is extended. Currently, "expired around the same time as the primary key" means up to +/-10 seconds different expiration dates. The normal use case is primary key with not expiring subkey (which is or was the standard result of creating a key; this is covered by condition 2) or primary key and subkey with same expiration date (which also is or was the standard result of creating a key; this is covered by condition 3).

If somebody adds a few more subkeys (e.g. a separate authentication subkey) just after creating the primary key then they may expect that those subkeys are extended together with the primary key. This would be an argument for allowing a greater expiration date difference, e.g. +/-1 hour.

On the other hand, the only truly transparent solution is a checkable list of all subkeys, so that the users can explicitly tell Kleopatra what they want and Kleopatra doesn't need to guess.

As in my test case Kleopatra didn't check the box for "with subkeys" when the extension wouldn't work I propose as minimal solution:

  • disable the checkbox if no key would be extended anyway + info why the box is not checkable (via tooltip)

In case some subkeys could be extended and some not the best solution is debatable...
Kleopatra could maybe extend the keys for which it is possible and show an info window listing the keys for which it wasn't done? Plus advice to go to the command line to extend them if that's wanted.

aheinecke claimed this task.
aheinecke added a subscriber: aheinecke.

I think this currently is fine. You can always go into the subkey view and the the expiry date there for corner cases.

But like it is now one would only go into the subkey view after things start behaving unexpectedly. After all, "I told the program to extend the subkeys", why should I verify if it really did this?
If the box "extend validity for subkeys" could not be checked in case no keys will be extended, I would then go to the subkey details, if I wanted to extend them, too.

If things start unexpectedly you already went to the console to change it or already changed it in the subkey view. Otherwise it is too intelligent for my tase since I have subkeys for example with different expiry dates. But nearly all users won't have that. I think the current solution is good. But @ikloecker can you change it please to +/-1 one hour you are right that the time window is too short.

It seems I did not express myself clearly.
I would prefer it if the "with subkeys" checkbox could not be enabled in case it won't extend any subkeys anyway.
With a bonus tooltip.

Ah, sure that also makes total sense, I thought you wanted it disabled if it did not extend all subkeys.

ikloecker changed the task status from Open to Testing.Mar 12 2024, 1:26 PM


  • The maximum allowed difference of the expiration between subkey and primary key is now +/-1 hour.
  • If the user has no choice whether to update the subkeys together with the primary key (because either all subkeys will be skipped because they don't fulfil the conditions mentioned in the first comment or because the subkeys share the expiration of the primary key) then the checkbox is not shown. That was easier to implement and it doesn't confuse the users with a "choice" they are not allowed to change.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.May 7 2024, 11:13 AM
ikloecker added a project: vsd33.
ikloecker moved this task from Backlog to WiP on the vsd33 board.