In T6632: Okular: Highlight / preselect "nonRepudiation" certificates for qualified signatures I had the impression, that some hint is useful for signing operations. Probably not so much in general.

Done and backported for VSD 3.4

checked with vsd 3.3.5: no change

Highlighting QES is mostly useful for Okular, I guess.
Maybe use a symbol with a pen? That should be self-explanatory.

We'll go with solution no 2 (which is in effect the same as no 1 anyway)

I misunderstood this, the mail can be forwarded with attachment if you first deselect the mail and then select it again. So the workaround is OK.

We decided to still use the term "Valid" (with description/tooltip "Certificates that are neither expired nor revoked (except disabled ones)"). This matches the use of the term "invalid" for expired and revoked certificates as in "Certificates that are invalid because they have expired (except disabled ones)".

This overloading of "bold" for "my certificates", "qualified certificates" and "trusted root certificates" seems to exist since two decades. I stopped digging into ancient history at the commit that added the hard-coded default filters.

Take care: Too many attributes (color, font) are bad style.

Well, the qual flag should only be set for CAs dedicated to certifying QES certificates. And those should by definition be signature certificates only, afaik.

Backported for VSD 3.4

Done. Example (with default text in English and German translation):

[Welcome]
welcome-text[$i]=<h2>Hello, World!</h2>
welcome-text[$i][de]=<h2>Hallo, Welt!</h2>

Ready for testing

I added the gpgsm log output (same error as in the gpg log)

Ah, thanks for the pointer, I did not expect gpgsm to behave differently here. Then it's probably intentional and I'll close this as invalid.

The gnupg manual (page 113) mentions:

works in vsd 3.3.5

As a first step we should make the diagnostics output available everywhere via a button like in T6268: Kleopatra: Diagnostic output when importing keys

We decided not to do this.

@mmontkowski, use this as string:

For now I'll commit the following German translations, fixing spelling plus other slight changes:

My actual plan is to rework the imp[ort/export of secret keys to gpg-agent. Right now gpg-agent has knowledge of OpenPGP for import/export. This is not good and the required conversion should be moved to a helper tools for easier testing and to have this out of the gpg-agent process. For Kyber we right now don't use any conversion mut store the secret keys in gpg-agent's native format. Thus the passphrase is not necessary. We need to figure out why we have this problem here.

This ticket is explicitly about Kleopatra included in Gpg4win.

In T8059#212270, @bernhard wrote:

Kleopatra is also run on GNU/Linux Distributions.

Kleopatra is also run on GNU/Linux Distributions.

works in Gpg4win 5.0.1 with GnuPG 2.5.17

To reproduce the hang, a loop will suffice (usually happens within the first 15 times, once it needed 50 runs):

This is still open. It cannot be tested because Gpg4win still doesn't use KIO::move on Windows (because the above patch has not yet been merged).

There's no other configuration, this happens with a clean gnupghome with one smime cert + root cert and the above gpgsm.conf (output on stdin/stderr):

I think this is still open (and requires T6537: Make KIO::move work on Windows when moving between different partitions).

Please run with --debug 0 which should show you which confiration files are read in which order. Is there anything in a common.conf file? A log-file statement tehre would overwrite the command line option.

Current state needs to be tested

Current state needs to be tested as soon as T7509: gpg4win: Make the AppImage build work with the new Docker-based build script is resolved

@werner: Is this resolved?

Fixed and backported for VSD 3.4

Backported for VSD 3.4