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

Assigned To

Authored By

	• ebo
	Jan 24 2024, 2:55 PM

Description

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.

gpgme_log.txt717 KBDownload

Details

Version: Gpg4win-4.3.0-beta571

Revisions and Commits

rKLEOPATRA Kleopatra
	rKLEOPATRAbbade74dfd1f We have to count the number of real subkeys, i.e. without the primary key
	rKLEOPATRA11165ce21b04 Consider a difference of up to 1 hour as same expiration as primary key
	rKLEOPATRA488aa46cf804 Offer user the choice to change the subkeys only if there is a choice
	rKLEOPATRA99da94290d07 Offer user the choice to change the subkeys only if there is a choice
	rKLEOPATRAa69601300c69 Consider a difference of up to 1 hour as same expiration as primary key

Related Objects

Mentioned Here: T6473: Kleopatra: "Change Validity" does ignore the option "Also update the validity period of the subkeys"

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.

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.

• ebo reopened this task as Open.Feb 8 2024, 1:41 PM

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 added a commit: rKLEOPATRAa69601300c69: Consider a difference of up to 1 hour as same expiration as primary key.Mar 12 2024, 11:42 AM

ikloecker added a commit: rKLEOPATRA99da94290d07: Offer user the choice to change the subkeys only if there is a choice.

ikloecker added a commit: rKLEOPATRA11165ce21b04: Consider a difference of up to 1 hour as same expiration as primary key.Mar 12 2024, 11:48 AM

ikloecker added a commit: rKLEOPATRA488aa46cf804: Offer user the choice to change the subkeys only if there is a choice.

ikloecker added a commit: rKLEOPATRAbbade74dfd1f: We have to count the number of real subkeys, i.e. without the primary key.Mar 12 2024, 1:21 PM

Changes:

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.