- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mon, Feb 2
Ready for testing
Tue, Jan 27
In T8059#212270, @bernhard wrote:Kleopatra is also run on GNU/Linux Distributions.
Mon, Jan 26
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).
This is not yet fixed. KDE still applies a patch to gpgmepp (and gpgmeqt) to ifdef a few GCCisms.
Thu, Jan 22
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
Wed, Jan 21
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.
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":
Implemented and backported for VSD 3.4
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
gpgme logs (also of vsd-3.3.4) will be useful.
Fixed and backported for VSD 3.4
Mon, Jan 19
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:
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.
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).
Fixed.
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.
Jan 15 2026
I don't know how I'm supposed to change/fix this. Not even gpg does what the ticket wants (see the sub ticket). And gpg doesn't report sufficient information to Kleopatra via gpgme. In fact, gpg doesn't emit a STATUS_TRUST_* message if the signing key is expired. Hence, gpgme reports "unknown" validity for the signing key, so that Kleopatra would always print "The used key is not certified by you or any trusted person." for expired keys even if the key was fully certified before it expired.