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>

Backported for VSD 3.4

This is actually a (known) bug in gpg, i.e. gpg --delete-secret-and-public-key PRIMARY_KEY_FPR only deletes the public key for keys without primary secret key.

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 have this now for VSD, there is (currently) no neccessitiy für Ggp4win

As there are there are no user requests for this, we'll close this

meanwhile we do not show a percentage any more so this is resolved

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.

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).

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

While key generation works now with an expiry date up to 2106-02-04, the representation on the command line is a bit ugly.

Current state needs to be tested

We need to test the current state

Fixed and backported for VSD 3.4

Backported for VSD 3.4

I have split out the "Tab navigation in the Smartcard Dialog is broken" issue because it's unrelated to this ticket: T8051: Kleopatra: Tab navigation in smartcard table is broken

Backported for VSD 3.4

I think this is a very good idea. Go ahead an backport, I'll change the ticket description accordingly.

We need to retest this with vsd34 as @ikloecker backported some tab related things after the 3.3.4 release.

Backported for VSD 3.4

I'll wait for feedback before I backport this.

Instead of adding yet another option I have optimized the case that a single archive containing a single top-level folder is decrypted/extracted (which, typically, is the result of encrypting a folder). In this case, the single top-level folder extracted from the archive is moved to the user-given output folder instead of the outer temporary folder the archive was extracted to. I think that's what most users anyway expect so that an option is superfluous. In case the extracted folder clashes with an existing folder in the user-given output folder then, as usual, the moved folder gets a numbered suffix to avoid the naming collision.

I'm fine with the current state in 5.0, I could live with keeping it like that for GPD, i.e. the import list (which will not be used often, anyway) has it's on memory.

In T7455#211913, @ikloecker wrote:

In T7455#211465, @timegrid wrote:

Issues found:

• The "Finish" button in the "Sign/Encrypt" dialog turns to "Sign/Encrypt" sometimes after successful execution:

I've seen this at least once. No really related to this ticket, but I'll have a quick look.

In T7455#211465, @timegrid wrote:

Issues found:

• If pgp is preselected, the "Sign..." operation will also check "Encrypt for others":