Thanks for clarification. I added this to the doc enhancement ticket https://dev.gnupg.org/T7911 and set this ticket to invalid.

Test with beta32

I think this is a matter of imprecise documentation.

So, for the current vsd docs (3.3): https://gnupg.com/vsd/kleopatra-settings.html
This would be more correct, if i understood it right?

HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra
HKEY_CURRENT_USER\Software\Wow6432node\GNU\Kleopatra

My point about action restrictions was to add one sentence in the docs section to clarify, what exactly is restricted then.

I think there is a misconception about Action Restrictions. Yes, they exclusively disable the corresponding action, i.e. the action is hidden (from menus and toolbars) and the keyboard shortcuts won't do anything. Action restrictions are no means to disable certain functionality as a whole like "Add User ID". Just because somebody listed all available actions in the documentation (which is rather questionable in my opinion) doesn't mean that it makes sense to remove those actions. Maybe only relevant/important actions should be listed so that the readers are not drowned in a huge list of largely irrelevant settings.

For settings in VSD 3.x best look at https://dev.gnupg.org/source/kleo/browse/gpg4win%252F24.05/src/kcfg/settings.kcfg (gpg4win/24.05 branch).

This looks questionable:

HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra
HKEY_CURRENT_USER\Software\GNU\Kleopatra

Either both keys use the 32-bit compatibility path Wow6432node\ or both keys don't. 32-bit builds (like VSD 3.x) will use the compatibility path (without being aware of the redirection). 64-bit builds (like Gpg4win 5.x) don't use it. Since Windows mirrors some settings between both registry paths it may not matter.

Allright, then the dash notation for those two groups are intended and the documentation needs to be adjusted

I suspect that the author of the documentation confused the (internally used) "name" of the settings with the "key" that's used in the config files (and the registry). For reference: Many settings are defined in https://dev.gnupg.org/source/kleo/browse/master/src/kcfg/settings.kcfg .

Note: The tab name is displayed after restart, if

• The tab was renamed manually
• The filter was changed (leading to a rename)

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:

Then I don't see how we can avoid this. It should be easy to reproduce this with gpgconf alone if you know how to use --change-options manually. Simply set the LDAP server that's already configured in the global config file.

gpgconf does not know about the global config files. Nor does it known about things like gpg.conf-2 etc.

Looks good to me on gpg4win-5.0.0-beta395 @ win11

I guess this is easy to explain:

1. gpgconf/gpgme reads the LDAP server from the global config
2. You add a second LDAP server (I don't think it matters if it's the same as the one from the global config or different one)
3. When you save the LDAP server then gpgme/gpgconf writes both LDAP servers to the local config
4. When you now read the LDAP servers you get one from the global config and two from the local config

Might there be a relation to T7842? But I would have thought that then all signed messages would be unaffected.

This issue should be fixed in 2.6, too.

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)

I'm fixing this issue under T7855. So, I move this ticket as a child of T7855.

@timegrid Thank you for your confirmation.

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.

I can't reproduce this in vsd-3.3.90.19 @ win10 anymore.
Probably the fixes in https://dev.gnupg.org/T7827 or https://dev.gnupg.org/T7855 solved this, too.

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

Might this be related to T4953?

related to T7843: GpgOL: Empty OpenPGP mails with "Read as plain" activated

(auto resolved due to the keyword "resolved" in the commit message)

The window was not reenabled on failure see 8d174d5

That is on purpose. With a signed mail you have at least a way to tell who sent the mail. An unsigned but encrypted mail can be send by anyone and you netter don't use HTML links there.

(removed: wrong statement)

Note: I also activated Sign/Encrypt by default, if that matters

see also https://dev.gnupg.org/T7609

ECC support for X.509 and in particular pkcs#12 format is limited. That is in general not a problem because such certificates are stored on a token and not on disk.

Tested with VS-Desktop-3.3.90.12-Beta

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