This issue can be resolved in my opinion, as I have tested the 64 bit installer and tested a 64 bit pg4win. The current status of this is that we don't want to have different library names depending on the architecture since it is installed in the same way as linux in different directories. So there is nothing left to do here.

My suspiction with this is that here the exchange server / outlook parses the mail attachment into MAPI and somehow handles mails differently then other attachments. This automatic conversion regarding attached mails is why we always ask users in Support to send us a problematic mail as a file in a zip archive. Otherwise Exchange will convert an attached Outlook MAPI mail to MIME and on the receiving side we can no longer see the original strucutre. Similar things are probably happening on the receiving side where the MIME eml "file" is converted into a MAPIOBJECT holding the forwarded mail which then confuses our internal knowledge about the attachments causing this error.

This works now.

I tested it and updated the community wiki documentation to refer to it.

I am observing strange beavior on WIndows 10 22h2 and OL 16.0.17830.200056 even if no mail is displayed in the reading pane and the selection returns no selected mails, Outlook loads mails which are e.g. right clicked. I think a way which could prevent some problems and allow it again to change flags and categories for unselected mails would be for us to check in the Read event if the mail has some inspector and abort in that case. This could also increase compatibility with other addins. I will do some experiments with it.

Well for 3.3 we will have full support for high contrast with the correct icons on all platforms, additionally we detect and support dark mode on all Windows 10 Versions > 1709 So this can be resolved. (Both for Qt5 and 6). What I have not yet checked if Qt6::systemInfo::colorScheme reports the correct one under windows 11 desert theme, but as you mention that is also part of a different issue where when then also should clean up the kleo systeminfo etc. if this is reliably supplied as information by qt.

Well, my hope for this was some kind of Format where we keep the keys + the signature together with encrypted files. Because I think it is an extremely common usecase to decrypt a file, modify it and then to reencrypt it to the recipients that it was encrypted to before and I think it would be a good usability improvement if after decryption, when a file is then encrypted again Kleopatra would have the recipient dialog prefilled with the original recipients. T6564: Kleopatra: Re-encrypt an encrypted folder to the original recpients And for Gpgpass this could be used in exactly the same manner just with a diffrent UI and focused on folders with multiple files.

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,