Test with beta32

VS-Desktop-3.3.90.31-Beta shows no warning any more for the export of a newly generated key.

So this means, the order in the description should be implemented, right?

Yes, by definition an immutable group doesn't allow any changes for that group. Don't mark a group as immutable if you want to allow changes.

The [KDE Action Restrictions][$i] in XDG_SYSTEM_DIRS/kleopatrarc prevents any changes within the whole group afterwards.
I guess, this is intended by defining an "immutable group", but i doubt that we want to prevent admins to change those settings?

So, regarding the minor version change: the change of order seems not critical (as there was no settings file before), but the introduction of the settings file might be.

I verified, that both in vsd 3.3.2 and vsd 3.3.3 beta90.29 the current implementation is

And we shouldn't change the precedence in a minor release, I believe.

The configuration readout order still needs to be specified/fixed.

Looks good to me on vsd-3.3.3-beta90.29 @ win11

Backported for VSD 3.4 and VSD 3.3.

I couldn't reproduce the problem because I had apparently told Kleopatra in the past "Do not ask again". :/

gpgme log for key creation and export with warning for VSD-Beta29

This is also the case in the latest VSD-Beta29

And when I switch of read-as-plain, both testmails in the inbox are displayed as expected but one of the ones from the sent-folder has an empty body:

This is a gif to show the UX. It is to complicated for words…

with 3.3.90.29-Beta:

Looks good to me on gpg4win-5.0.0-beta395 @ win11 (tested with/without keyboxd, 20 keygen rsa3072 each, with/without password)

that's probably at least partly another issue: https://dev.gnupg.org/T7843

additionally, the body of the messages is (in most cases) not shown any more.

With the beta-25 the body of the mail is not saved back to the server any more but the security level tags are. So the test mail still seems to be a signed and decrypted empty mail even if you deactivate gpgol.

We did decrypt the mail successfully and called put_oom_string to update the Body successfully, but for some reason for new mails the put calls succeed but the displayed Text is not updated i.e. no "OpenGPG Message Please wait..." or decrypted message.
When closing the mail window the mail is still open in the preview pane and we should get back the mail content (Body), but we don't get back what we set with the put call but what is displayed i.e nothing (empty string).
So we pass on the close call which does write back our put value. (Plaintext leak)

Happens on vsd 3.3.2, too.

At which point did were you asked for the passphrase for decryption? You flushed the gpg-agent cache, right?

In pgp signed unencrypted text mails it happens, too, that first the "converted to plain text" message is shown without content, and after open/close the message is gone and the content is displayed.

with VS-Desktop-3.3.90.19-Beta, and settings disableAutoPreview and ReadAsPlain

with VS-Desktop-3.3.90.19-Beta, and settings disableAutoPreview and ReadAsPlain

Shall we merge this with T2196 ? BTW, I have some unpushed commit and a test installer.

Here are places where I found problems.

The regression that the Welcome screen didn't go away after generating the very first key has been fixed. The fix has been backported for VSD 3.4 and VSD 3.3.

As this was finished more than a year ago, this should be included (and testable) in vsd

Fixed and backported for VSD 3.4 and VSD 3.3.

The following workflow works for Markus and me:

Will be backported after 2.2.49

FWIW: The fix rO75f46829054e is part of GpgOL since 2.6.3

Tested with VS-Desktop-3.3.90.12-Beta

Same behavior (on vsd-3.3.3-beta90.12 @ win10) for smime encrypted mails:

Looks good to me on vsd-3.3.3-beta90.12 @ win10:

what ever was fixed with the attached commit we can not test.

Tested with VS-Desktop-3.3.90.12-Beta, GpgOL 6.5 (WIN10 and WIN11)

2.2 test can be done with GnuPG-VS-Desktop-3.3.90.12-Beta-Standard.msi from Sep 17

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)

Backported to 2.2 but not yes tested with 2.2

Sorry, I just found out, that windows caps the filename earlier than max length, so my former tests were invalid.

All mails touched by gpgol should already have a GPGOL_UID_DASL. So to replicate:

1. Send a new encrypted mail (e.g. Edward -> Ted)
2. Don't open that mail, but open the context menu: Move -> Other Folder ...
3. Select a subfolder of INBOX and click OK -> the mail is not moved

Tested with VS-Desktop-3.3.90.8-Beta and the test gpgol.dll from 2025-09-10 and the same test mail from the original report:
The spawning cycle does not occur any more. (Tested with Outlook setting "show as text only" and without.)

Andre mentioned in 10721b1dccf4 that "Closing the mail this early might also have contributed to
endless loops of read + close" which is what we see here as well

How to test this? The follwing happens for an attachment of an encrypted mail on gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10:

Moving an encrypted message on Gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10 into an inbox subfolder of Ted.Tester and back works for me, too. Does this confirm, that it's working now?