I implemented that in the old 2.2 branch for easier testing.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 2 2025
Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.
I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.
Oct 1 2025
The gnupg_remove should retry if it has a sharing violation. Similar to what we do in gnupg_rename_file. I just figured that we do a remove in the latter function too w/o handling a sharing violation.
Here is a possible fix:
Sep 30 2025
Fixed and backported for VSD 3.4 and VSD 3.3.
Sep 29 2025
Sep 25 2025
We were testing different things. This instance of the move to folder issue is fixed, for variants we'll open new tickets with clear test cases.
Sep 24 2025
Also implemented for 2.2
The following workflow works for Markus and me:
FWIW: The fix rO75f46829054e is part of GpgOL since 2.6.3
Same behavior (on vsd-3.3.3-beta90.12 @ win10) for smime encrypted mails:
I can't find any causes of slowness in keyboxd initialization. I think that there is a situation where it simply takes time on Windows.
Sep 23 2025
Looks good to me on vsd-3.3.3-beta90.12 @ win10:
what ever was fixed with the attached commit we can not test.
I see no workaround.
The attachments in the original mail are not gone, yes.
But the mail can't be forwarded with them.
Tested with VS-Desktop-3.3.90.12-Beta, GpgOL 6.5 (WIN10 and WIN11)
Test with 3.3.90.12-Beta:
The test mail from before does not cause a spawn cycle and no high CPU load any more. (Tested without "show as text only", as it was not relevant before.)
Looks good to me on vsd-3.3.3-beta90.12 @ win10 (temporary filename is now attachment.odt or e.g. attachment (002).odt)
Debug log for vsd:
Also still present on vsd-3.3.3-beta90.12 @ win10 (mail is not moved)
Sep 22 2025
After a discussion we decided to drop the idea to save the status of the check boxes even for only the box "encrypt for others".
Current logs for a forever hang:
still reproducible on gpg4win-5.0.0-beta369 @ win10
In T6117#205379, @ikloecker wrote:I guess this is a typo because the CSR looks like an encryption-only certificate.
Sep 19 2025
I think this will make the dialog less user friendly because with this change one always needs to check the status of all check boxes. Without the change the check boxes always have the same status when the dialog is opened the same way. Predictability is very important for usability and even more for accessibility.
I would like to change this ticket to "Save status of all check boxes in the sign/encrypt dialog".
ok, changed the text in the description of the ticket accordingly, but put two more "team" back in.
Dialogtext (winzige Politur):
Sep 18 2025
We decided to
Looks like there is a rights problem modifying the body of those mails
Every time when we try to modify the HTMLBODY or BODY property we fail with MAPI_E_NO_ACCESS.
The attached mails in those tests where ms-tnef formated (winmail.dat)
omhelp.cpp:lookup_oom_dispid:160 wchar_t alloc 00000155d9abfe80:HTMLBody
07:35:08/5284/oomhelp.cpp:put_oom_string:674 wchar_t alloc 00000155ccf77710:<html><head></head><body><table border="0" width="100%" cellspacing="1" cellpadding="1" bgcolor="#0069cc"><tr><td bgcolor="#0080ff"><p><span style="font-weight:600; background-color:#0080ff;"><center>OpenPGP Nachricht</center><span></p></td></tr><tr><td bgcolor="#e0f0ff"><center><br/>Bitte warten Sie w�hrend die Nachricht entschl�sselt / gepr�ft wird...</td></tr></table></body></html>
07:35:08/5284/oomhelp.cpp:put_oom_string: Putting 'HTMLBody' failed: 0x80020009
07:35:08/5284/DBG_OOM/oomhelp.cpp:dump_excepinfo: Exception:
wCode: 0x1000
wReserved: 0x0
source: Microsoft Outlook
desc: Sie besitzen nicht die erforderliche Berechtigung, um diesen Vorgang auszuf�hren.
help: null
helpCtx: 0x0
deferredFill: 0000000000000000
scode: 0x80070005
07:35:08/5284/TRACE/oomhelp.cpp:put_oom_string:699: return
07:35:08/5284/ERROR/mail.cpp:decryptVerify_o: Failed to modify html body of item.Sep 17 2025
We got new suggestions for this:
Sep 16 2025
I found and fixed a bug (likely a regression in the new code): When CN_prefill or EMAIL_prefill is configured as true and no fixed CN or EMAIL is configured then Kleopatra should prefill Name and Email with values taken from CONFIGDIR/emaildefaults (used by KDE apps on Linux), from the Windows user or from the EMAIL environment variable. This didn't work anymore.
To query the AD I used the GPGME function gpgme_op_assuan_transact_ext with an query string like this:
ad_query --subst --attr=dn,userAccountControl (&(objectcategory=person)(objectclass=user) (|(userPrincipalName={{email}}) (mail={{email}})))Of course {{email}} must be replaced with the mail address queried, this might probably also be the UserPrincipalName.
Meanwhile we notice this also with OpenPGP Mails. This needs to be further investigated.
Sep 15 2025
We'll keep it as it is, for the improvement see T7814