Today
Backported for VSD 3.4
I think this is a very good idea. Go ahead an backport, I'll change the ticket description accordingly.
Re-opened because a regression is reported.
Yesterday
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.
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
The first time Okular was included is gpg4win-4.2.0:
See here for how it should look like:
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:
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
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).
- VSD 3.3.4
- Gpg4win 5.0.0
Tue, Jan 20
- 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