Page MenuHome GnuPG

Kleopatra: change "certificate detailed view" to tabbed interface instead of sub-windows
Testing, NormalPublic

Description

From the "Certificate" window two more sub windows can be opened ("Subkeys" and "Certifications").
All this information should be consolidated in a slightly redesigned tabbed interface.
The following mock up is an example for one tab:

  • The common information of an certificate is moved to the top (fingerprint, validity, primary user ID, information regarding the private key)
  • below this are three tabs with information from the previously separate windows:
    • "User IDs" - from the primary window
    • "Certifications" - from the window opened with the button "Show Certifications"
    • "Keys" - from the window opened with the button "More Details ..."
    • (there is a fourth button in the screenshot which is part of another task)

Revisions and Commits

Event Timeline

alexk triaged this task as Normal priority.Feb 27 2024, 2:51 PM
alexk created this task.

Keep in mind that the "Certificate Details" can also be shown for search results in the server lookup. In this case not all properties are available, e.g. there is no information about certifications, so that it might not make sense to show the certifications tab. Or we show the tab (so that the users don't wonder why it's missing), but display a message explaining that this information is not available before the certificate is imported.

TobiasFella moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Mar 12 2024, 1:10 PM
TobiasFella changed the task status from Open to Testing.Mar 25 2024, 3:23 PM

Optimization requests:

In details window:

  • add regular padding around the buttons in the tabs

Tab "Certifications":

  • Show Fingerprint instead of Key-ID of certifications (change the title correspondingly)

[edit: some bullet points moved to subtasks T7094, T7095, T7096]

I don't like blowing up a task with loads of unrelated additional wishes after the original request was fulfilled. At most the first request can be considered part of the original request. The other requests should be handled in multiple separate tasks.

Show Fingerprint instead of Key-ID of certifications (change the title correspondingly)

This makes no sense. A signature carries the (8-octet) key ID of the issuer. Optionally, the Signer's User ID might be attached to the signature. I don't see any mention of the issuer fingerprint in the published RFC for v4 signatures. Hence, for unknown keys it's impossible to show the fingerprint. And for known keys it would, in my opinion, give a false sense of security because we have to use the key ID to determine the key's fingerprint.

We include the ISSUER_FPR subpacket since version 2.1.16 released 2016. Thus there is virtually always a fingerprint for all signatures available.