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":

setting to High as we need this for T7790

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.

I create diff with implementation via VirtualLock WinAPI: https://dev.gnupg.org/D622

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.