This should no longer happen with Gpg4win-3.1.0 as GpgOL now uses gnupg's --locate-key mechanism to find a matching key.

In T3769#111899, @hs wrote:

Behavior is the same as 3.0.3 /3.1.0beta32.
It reads encrypted e-mails if Titus plugin is disables (GpgOL as the only plugin).

Could you please test again with the beta38 (or later) from https://www.gpg4win.org/version3.1-de.html It contains the change now.

I'm closing this as I've got confirmation that one crash was fixed by disabling async encryption again. And a class of general "Crash when encrypting" bugs that were related to the communication between Kleopatra and GpgOL no longer exists as Kleopatra is no longer used when encrypting from GpgOL in gpg4win 3.1.0.

Thanks for your report. This has been fixed for the next version ( https://bugs.kde.org/show_bug.cgi?id=391222 )

Thanks for testing and the confirmation / praise ;-)

The second user ID in my test case was an "URL". So we now use what ever the "raw" user id data is as the Name if both name and email are empty.

I don't find an easy way to fix this.

I just tested changing passphrases and indeed this is very ugly. Especially as this opens up a wide range of error states where you have different passphrases for different subkeys etc.

I'm not 100% certain but I think that it is likely that your problem is fixed with the upcoming 3.1 version. We have reworked how GpgOL encrypts there a bit ( T3509 )

The field is now renamed to "Activate GnuPG Profile" to make it more clear the the button activates a new profile.

I've added this to libkleo formatting now. But seeing it and thinking more about it I don't like it. As I think that the export is mostly for "You give this to others" information about the subkeys is too verbose. The current header should suffice as "some info for differentiating between keys".

Kleopatra now shows this:

This works now reliably in my tests.

Cancel is now handled and the key is not removed if the user canceled.

I got beta feedback which after analysis showed that parts of the encrypt changes in 3.1 that would have addressed this lead to crashes. So we had to disable it for now and block Outlook again as temporary blocking is better then "random" crashing :-((

With the tab layout I think that this is resolved.

I give this high priority as I would love to have this fixed for the next release.

Nope. The corner widget is the suggested way in outlook and users are used to it / accept it.

According to this thread on stackoverflow: https://stackoverflow.com/questions/32712399/c-sharp-vsto-outlook-itemsend-event-execution-order

Long enough time to object to just killing stuff. We are killers now. -> Resolved.