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

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.

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.

I also tested to add the qual flag to the root cert in the global trusted.txt, as using qualified.txt is considered legacy, but still the same behavior

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.

The first time Okular was included is gpg4win-4.2.0:

See here for how it should look like:

• https://invent.kde.org/graphics/okular/-/merge_requests/1120
• https://invent.kde.org/graphics/okular/-/merge_requests/1121

I see. I added the root cert to C:\ProgramData\GNU\etc\gnupg\qualified.txt and the usage of the signing certs does include a qualified signature in Kleopatra now. Still I don't see any highlight/filter in Okular:

In T7455#211465, @timegrid wrote:

Issues found:

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

Implemented and backported for VSD 3.4

The "ca" root cert is not on the ldap, if that matters

In T8048#211860, @ikloecker wrote:

some other certificates, but I guess those are from other tests

It also happens on CLI:

With Gpg4win 5.0.0 the LISTKEYS after the server lookup lists the (ephemeral?) ca@gnupg.test certificate and (!) the bob@gnupg.test certificate (and some other certificates, but I guess those are from other tests).

1. VSD 3.3.4

1. Gpg4win 5.0.0

• gpg4win 5.0.0 @ win11

gpgme logs (also of vsd-3.3.4) will be useful.

I have not checked but I guess that the certificate is marked as ephemeal and kleopatra either lists ephemeral certificates or the ephemeral flag got removed to to a validation process,

Note: This does not happen on vsd-3.3.4

Fixed and backported for VSD 3.4

None of these certificates are for qualified signatures.

Try compare with a gpg4win 3.latest.

The gpgme logs show that the information for revoked keys should be there. We just need to check for it (and somehow visualize it).

pub:o:3072:1:3DA05D6B0A5998AF:1768822823:1863514800::::::::
fpr:::::::::C70F6D8F32DFE96F5C47C40B3DA05D6B0A5998AF:
uid:o::::::::search (valid) <search@gnupg.test>\r:

gpgme.log (vsd 3.3.4):

Fixed. The problem was that the selected sections were stored in the 64-bit registry (unless browser integration was installed; see T8038), but they were read from the 32-bit registry.

Fixed.

Let's give this Normal priority.

Meh! The installation of the browser integration explicitly enables the 32-bit registry. Obviously a leftover from gpg4win 4.

In T8039#211727, @timegrid wrote:

I wonder where the information of the previously installed components comes from, if not from the MementoSection_SEC_kleopatra fields.

Thanks for checking! So now we know why the line is missing. Looks like installing browser integration causes a broken installation (at least with respect to registry keys).

I searched the whole registry and found, that if browser integration is installed, this key still lives in WOW6432Node: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Gpg4win

Oh, surpisingly it's the other way around: if the information is given in the registry key, all components are preselected. If the key is missing (browser integration installed), only the installed components are preselected. I wonder where the information of the previously installed components comes from, if not from the MementoSection_SEC_kleopatra fields.

Fixed.

Another possibility would be to just add a revoked column (expiration date is already shown) to keep closer to the ldap schema.

Without browser integrations installed, the preselection works fine though.
Probably this happens, because the info in the registry is missing as soon as browser integration is installed, see T8038: NSIS: Updating line omitted if browser integration is installed

should properly uninstall the existing installation.

Regarding 32-bit and 64-bit installers: The installer looks in both registry trees for the relevant registry keys, i.e. 64-bit over 32-bit and vice versa should properly uninstall the existing installation.

I understood that this is done on purpose, i.e. all other components are explicitly always preselected.

gpg4win-5 has no idea that gpg4win-4 is installed because the former is a 64-bit installer/application and the latter a 32-bit installer/application, i.e. they use different registry trees. More important that the missing "Updating line" is very likely that the gpg4win-5 installer does not uninstall gpg4win-4. I haven't checked if NSIS is capable of detecting/uninstalling a 32-bit application from a 64-bit installer.

see also T8039: NSIS: Preselection of installed components on reinstall only works with browser integration installed