show no text "not VS-NfD compliant" for invalid signatures

done in https://invent.kde.org/pim/libkleo/-/merge_requests/137

All changes proposed here have been implemented. I do plan more changes, but will put them in separate tickets

the changes themself look good to me on gpg4win-5.0.0-beta167@win10

single / valid
single / valid / subkey (using signing subkey)
single / valid / disabled
single / valid / expired
single / valid / missing
single / valid / revoked
single / valid / revsubkey (revoked signing subkey)
single / invalid
multiple / valid
multiple / valid / same (multiple sigs with same cert)
multiple / mixed
multiple / mixed / split (single file for each signature)
multiple / invalid
other / valid / trust (signed with all trust states)
other / valid / somesigned (only some userids signed)
other / valid / unsigned

edit 08.05.25: added single/valid/disabled, single/valid/revsubkey and other/*

bugs found:

• the Show Audit Log link will open the log only on the second click
• the encoding of the log seems broken
  

tests with vsd still needs to be done

Most of the texts (most are proper sentences) lack a full stop. It's unclear whether this is a bug in the German translation or also in the original texts. This should be fixed.

In case of multiple signatures we may want to use plural for the "file verified with ..." message, i.e. "<datafile> verified with N signatures from <sigfile>". This could be fixed.

It's weird that in the "multiple / mixed / split" case the full paths of the files is used even though all files seem to be in the same folder. This isn't really that important.

One thing: The message for the valid signature from a revoked key looks less worrisome from the user perspective as an invalid signature. Is this intended?
One does not see here if the signature was made before or after the revocation. In the latter case the signature can not be trusted for sure. In the first case it might be ok.

Could we maybe add the time of the expiry or revocation in the message?

It's weird that in the "multiple / mixed / split" case the full paths of the files is used even though all files seem to be in the same folder. This isn't really that important.

This is always the case, when the sig file is selected for verification (compared to the verified file itself). Makes probably sense, as the file to be verified needs to be selected explicitly and could be in a different path.

In T6869#200682, @timegrid wrote:

• the Show Audit Log link will open the log only on the second click

This is a known bug, but I don't think we have a ticket for it. Please create one.

• the encoding of the log seems broken

Apparently, gpg prints the time (zone) with a different encoding than its own texts (e.g. "EDDSA-Schlüssel"). I suspect that a POSIX function is used for printing the time and that one doesn't know that gpg wants to print everything with UTF-8 encoding. We wouldn't have this problem if gpg would use LANG=C. I'm wondering why gpgme doesn't call gpg with LANG=C to avoid any problems with non-ASCII characters. In any case, this is material for a separate ticket.

In T6869#200688, @ebo wrote:

One thing: The message for the valid signature from a revoked key looks less worrisome from the user perspective as an invalid signature. Is this intended?
One does not see here if the signature was made before or after the revocation. In the latter case the signature can not be trusted for sure. In the first case it might be ok.

Could we maybe add the time of the expiry or revocation in the message?

You cannot trust any signatures made with a compromised key because the signature creation date can easily be forged.

In T6869#200689, @timegrid wrote:

It's weird that in the "multiple / mixed / split" case the full paths of the files is used even though all files seem to be in the same folder. This isn't really that important.

This is always the case, when the sig file is selected for verification (compared to the verified file itself). Makes probably sense, as the file to be verified needs to be selected explicitly and could be in a different path.

If the file data is next to the file data.sig then Kleopatra should automatically use data.sig with data. If you run kleopatra --verify data.sig or start the verification by selecting data.sig in the Windows Explorer then Kleopatra does automatically use data (at least on Linux).

In T6869#200687, @ikloecker wrote:

Most of the texts (most are proper sentences) lack a full stop. It's unclear whether this is a bug in the German translation or also in the original texts. This should be fixed.

"Bad Signature" has no full stop, but as it is no proper sentence, you likely mean the sentences ending with the fingerprint. In EN most end with "… fingerprint: %1" without full stop. In DE I decided on a sentence without the colon. I'll add a full stop there.

You cannot trust any signatures made with a compromised key because the signature creation date can easily be forged.

Then why don't we add at least the red background (and maybe an X) instead of the warning sign symbol and no color?

so the non working automatic match of data.sig -> data is another bug?

a note regarding the encoding: the originial screenshot did not have this bug yet:

sure, I'll create proper tickets tomorrow.

You cannot trust any signatures made with a compromised key because the signature creation date can easily be forged.

Then why don't we add at least the red background (and maybe an X) instead of the warning sign symbol and no color?

I don't know. How to treat not-valid signatures is a topic for long discussions. One view is that there are only two states that one needs to differentiate: The signature is valid (i.e. it is good and the certificate is trusted). The signature is not valid (for some reason) or it couldn't be verified. Another view is that there are three relevant states: valid, invalid, undecidable.

I'm not sure if using red to indicate danger is a good idea in any case. The most likely reasons for an invalid signature are probably:

• Transmission error, e.g. during message transmission the message was reformatted (this is by far the most common error when using email).
• In case of detached signatures: Using a wrong/outdated detached signature to verify a signed file.

None of those reasons justify putting the user in alarm mode by using the color red.

Maybe we should use green for valid, white for undecidable (i.e. missing signing certificate), and yellow (or some other non-alarm color) for invalid.

The current code seems to differentiate the following three states:

• valid signature with valid certificate
• signature doesn't match the data
• signature with missing, expired or revoked certificate

I can see why treating expired and revoked certificates the same as a missing certificate can make sense.

In the end I'm coming back to the two states view: Either the signature is valid or not. Kleopatra cannot know/decide if a not valid signature is a problem and should maybe treat all "not valid" cases (including the "couldn't verify because of missing certificate" case) the same way.

I'm wondering how we display valid signatures with not certified certificates. Those should probably be white (because there's no problem with signature or certificate, but signatures of uncertified certificates are as good as no signature at all.)

In T6869#200695, @timegrid wrote:

so the non working automatic match of data.sig -> data is another bug?

It's a bug if it's a regression. Otherwise, it's just an annoyance for the users that should be fixed. I'm sure some users would consider it a bug.

a note regarding the encoding: the originial screenshot did not have this bug yet:

Interesting observation. Maybe the screenshot was made before we switched the output of gpg to UTF-8 to avoid/fix all kinds of other encoding problems.

i added single/valid/disabled and single/valid/revsubkey to the screenshot table:
https://dev.gnupg.org/T6869#200682

In T6869#200687, @ikloecker wrote:

Most of the texts (most are proper sentences) lack a full stop. It's unclear whether this is a bug in the German translation or also in the original texts. This should be fixed.

It's not the translation:

I'm wondering how we display valid signatures with not certified certificates. Those should probably be white (because there's no problem with signature or certificate, but signatures of uncertified certificates are as good as no signature at all.)

I added other/* to the screenshot table:
https://dev.gnupg.org/T6869#200682

• trustlevels of signed certs don't make any difference (as expected)
• unsigned certs (other / valid / unsigned) are already white
• certs with only some userids signed (other / valid / somesigned) are displayed as "not certified" in table (although listed in filter "certified"), and are green. makes sense i guess, that it can be trusted, if at least one userid of the certified signing key is signed

If the file data is next to the file data.sig then Kleopatra should automatically use data.sig with data. If you run kleopatra --verify data.sig or start the verification by selecting data.sig in the Windows Explorer then Kleopatra does automatically use data (at least on Linux).

Sorry, the autoselect on .sig verification does work (as well as the other way around). The example above uses 4 sig files with different names, that obviously just don't match.

But if the data file is chosen, the filenames are displayed, and if the data.sig file is chosen, the absolute paths are displayed - which is probably related to the changesets in this ticket, so i don't open a new one.

These issues are split off into new tickets:

• T7644: Kleopatra: 'Show Audit Log' in signature verification needs two clicks to open
• T7645: Kleopatra: Encoding errors in signature verification audit log