I understand the problem now. The difference between my test yesterday and today was that I had disabled S/MIME support in my GpgOL. Since T7243: GpgOL: multipart/signed OpenPGP SMTP transfered mails are displayed as S/MIME is an issue that makes GpgOL think that it is looking at an S/MIME mail but S/MIME is disabled, it tries to write back the mail to the server in a way so that Outlooks internal S/MIME support can parse it on the next run. In the log you see:

Today this was reproducible for me, too. Not sure what the difference is yet to yesterday I could see in my logs that this time the mails were never completely unloaded so that might be a reason. But we cannot rely on that. So reopening mails must work of course even if the mail stays open. (Good to simulate by keeping outlook spy active on the mail when loading and unloading).

To clarify what I mean by the missing VarFileInfo block. Currently the GnuPG binaries have versioninfo.rc files but only the version number is displayed for dlls as their pattern did not have the VerFileInfo block: The libassuan-0.dll displayed in this screenshot is from the 2.2.43 package and the assuan-9.dll is self compiled but including the patch below that. I would like to commit such a patch to all libraries that require it if that is okay with you.

Using signed files would have been my suggestion, too. For me I would say that "allowed to sign" depends on the ownertrust of the signature certificate. If the ownertrust of the certificate is Ultimate then you can accept the recipient list. Ultimate ownertrust is given for your own keys or for the ones marked with trusted-key in the GnuPG configuration.

I cannot reproduce the duplication, there are probably errors in your log regarding that close / discard changes failed or something like that in this case as we leave the original message intact and only add the extracted mime parts as attachments and replace the body with the text mimepart. It would duplicate that when it would "reverrify" a mail that already went thorugh all this. But it is meant that while the mail exists in outlooks memory that GpgOL tracks that, too and so does not decrypt the same mail twice. What I can see is that multipart/signed without encryption is somehow parsed as S/MIME initially. This looks like some new behavior in Office 365 or recent versions of Outlook when the message class is changed to an S/MIME Message class. Which we do to get unmodified access to the MAPI structure. From the data objects looking at the mail in outlook spy:

In T7237#189558, @ikloecker wrote:

"Holder" doesn't exist for anything but OpenPGP cards and many people may not set it. Hence, I think it makes little sense to show this in a prominent location if it's empty for most users who don't juggle with loads of OpenPGP cards.

As I could not reproduce the issue with different builds I realized that I was compiling and linking GpgOL for development using a very different version of winpthread.
When I switch to a consistent build and runtime library the crash no longer happens. I wonder if we can maybe statically link winpthread, too. But I think that is coming from Gpgme++ since GpgOL only uses windows threads.

Name, E-Mail, Status, Valid From, Valid Until, [Protocol], Key ID, [Fingerprint], [Certification Trust], [Origin], [Last Update], [Issuer], [Serial Number], [Tags], [Algorithm], [Keygrip]

I added some comments to the commit. But

This works suprisingly well, without explicit invalidations i would not have expected that get icon is called automatically after the button or a subbutton is clicked. But I think that this then would require at least a test on the oldest supported version from us, too. Do we even have an old GpgOL test system?

Markus this ticket I find important as it has much user visible impact. While VS-NfD secops say you "should" not use H TML mail, most users and basically all non - VS-NfD users use the default of outlook anyway and use HTML.

I mean the system configuration of Windows is just strange and messy. I am only noticing this now more because for my latest Test VMs I used VIrtual Box unattended installation, which installs the system according to the Hosts locale and then you can change the language for your user in Windows. And I ended up with this setting here where the preferred languages differ from the Windows UI language. And we are not alone in a confusion, on this system also Paint is in english, and the Microsoft Calculator, but not Powershell or CMD 🙄 But as GetUserPreferredUILanguages should return (and does according to my tests) the display langue chosen in the drop down as Language[0] and the others with lower priority I think the correct behavior here is to be in German.

In T3733#189355, @ikloecker wrote:

Don't change the existing KDE behavior for loading the correct Qt translations which is the same as gettext's behavior. It took quite some time to get it right on Windows for KDE.

With debug output I have confirmed that KConfig uses the defaultLocale at this point to read the VS-NfD name. So one issue here is that KConfig needs to use the Language configured for translations when reading out the config from which we take the VS-NfD name.

We have solved this now by showing a configurable error message in that case instead of hard failure with a cryptic error in T6683: GpgOL: Configurable error if sign is selected and prefer_smime

Noticed this again that it was very slow. I guess how fast it is depends on your wine configuration. I worked it around by disabling winepath for me again. But do we want to change anything here or just move this to wontfix?

I notices this again, even though my display language is german and Kleopatra is german the GnuPG system is using english (gpg-error --locale says en_IE). en_IE was set by virtualbox during windows installation. No environment variables are set related to language.

For pinentry I used the QGuiApplication::styleHints()::colorScheme() API in T7230: pinentry-qt: Show passphrase icon nearly invisible in dark mode and high contrast so I think we finally have this covered.

Tested on Linux, modern Windows and Windows 10 2016.

Hi Bernhard,