Kleopatra and key resolver: Use the blue symbol for non-compliant keys
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• ebo
	Oct 2 2023, 1:49 PM

Description

If one key in a large Kleopatra key group or in a long list of single recipients for an encryption has a non-compliant algorithm this is difficult to spot:

You automatically scan for green check marks and the missing "VS-NfD compliant" is easily overlooked. Any ideas how to remedy this?

Maybe a checkmark in another color? Or we could maybe sort the offending keys to the top?

For the groups it would maybe be sufficient to improve the group dialog in regard to this.

Update: We decided on the blue symbol for the non-compliant keys

Details

Version: VS-Desktop-3.2.0.0-beta229/231

Revisions and Commits

rLIBKLEO Libkleo
	rLIBKLEOd64ae173153f Use blue "info" icon for valid, but not compliant certificates

Related Objects

Mentioned Here: T6722: Kleopatra: Forbid adding non-encryption keys to groups

Event Timeline

• ebo created this task.Oct 2 2023, 1:49 PM

• ebo mentioned this in Unknown Object (Maniphest Task).Oct 2 2023, 1:53 PM

Sorting problematic keys to the front make sense to me, but might be complex since we just add the certificatelineedits and then would need to do some kind of dynamic layouting regarding on the return value of the linedits key.

I wonder if a button "Open Group Configuration" next to the name of the group would be most helpful here where we would make a process call to Kleopatra to bring up the group settings dialog for this group. That way a user can analyze remedy the situation for this group for the long term and does not need to make changes for each mail.

We decided to use the blue symbol for such a not compliant key in the VSD version

• ebo renamed this task from Kleopatra: Improvement of visibility of cause of non-compliance in encryption to Kleopatra: use the blue symbol for non-compliant keys.Oct 5 2023, 12:48 PM

• ebo updated the task description. (Show Details)

ikloecker renamed this task from Kleopatra: use the blue symbol for non-compliant keys to Key resolver: Use the blue symbol for non-compliant keys.Oct 13 2023, 11:14 AM

ikloecker added a commit: rLIBKLEOd64ae173153f: Use blue "info" icon for valid, but not compliant certificates.Oct 13 2023, 2:31 PM

Fixed.

• ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Oct 31 2023, 2:10 PM

For an OpenPGP group it looks now like this:

No sending possible.
When I remove the offending key (which could be made more intuitive for the user but thats not in the scope of this ticket):

Sending is possible.
This is both as planned IMHO.

But for a S/MIME group with not compliant certificates the group is not resolved:

I need the S/MIME group if I shall look into this. Are you sure that all S/MIME keys in the group can be used for encryption? Groups containing sign-only keys (OpenPGP or S/MIME doesn't matter) are never offered for encryption. That's why we wrote T6722: Kleopatra: Forbid adding non-encryption keys to groups.

Ok. With a simple group with one valid and one expired certificate it looks fine:

A revoked certificate works as expected, too. Only when I add a sign only certificate to the group it looks like the last screenshot in https://dev.gnupg.org/T6744#178272.

Therefore marking it as solved as this is covered by T6722

• ebo moved this task from Backlog to vsd-3.2.0 on the vsd32 board.Nov 13 2023, 3:41 PM

• ebo edited projects, added vsd32 (vsd-3.2.0); removed vsd32.

Note for myself: This is the behavior for key resolving in GpgOL. GpgEX has different code for this and the above examples will not work.
In GpgEX the group is not resolved into its component keys currently.