Thanks for the report. Prio High as this is data loss. I won't stop the 3.1.4 release which is currently in progress though as this issue does not appear to be a regression.

Your best bet is to try it on the command line to see if that provides some more useful output:

There is now an option in the debugging tab of the GpgOL config dialog to disable async decryption. This does not fully fix the issue but maybe mitigates it for some users that are very affected by this.

I decided today to install the beta version and give it a try, because the final version is not yet released. I still facing major problems, see attachment. The mail will not be delivered, but Outlook does not crash as before.

I finally got around to look at your examples. Sorry for the delay. I can reproduce the issue and understand the problem.

Thanks for the report I'll look into it. Won't make it into the next release though as we are currently very close to the release.

It's implemented.

I could reproduce it at first, but when trying to make a screenshot clip
from that, I couldn't reproduce it any more, no matter what. It's either
gone (mail server update?) or needs a very specific sequence of events
that is quite unlikely.

This required some changes in the keyresolver / newkeyapprovaldialog in libkleo, too.

Thanks for your analysis and the report. The good news is that we had this already reported and have fixed it.

gpg: keydb_search failed: Provided object is too short

So these are the results for gpg -K:

Thank you for your detailed report. Seems like something strange is broken on your system and our error handling does not properly cover that.

After several experiments with attachment flags to get the same behavior outlook does for unsigned mails I could not find a way to set both the content-id and cause the attachment not to be hidden.

The reason for this appears to be the "Content-ID", this is usually set for embedded attachments like images and not for attachments like PDF's.
This leads to the attachment being hidden, e.g. if you have embedded images you do not want them to show up in the list of attachments.

Turns out that that was not the problem.

In T4111#118259, @JJworx wrote:

That may be true, my Outlook crashes more often. Especially when dealing
with incoming S/MIME-signed mails!

This was a regression from 59e8a7ee3bcd16275091c9535626e49fc2a6c4af where a performance improvement to cache an object caused this problem.

Ah wait, I just remembered T4142. Maybe that is related. I'll try to reproduce that one first.

Again one of these issues I can't reproduce :-/

That may be true, my Outlook crashes more often. Especially when dealing
with incoming S/MIME-signed mails!

updated example sent.

The self test error message looks like it originates from https://github.com/KDE/kleopatra/blob/master/src/selftest/enginecheck.cpp

gpg -k works and displays the list of keys I expect. gpgsm -k returns nothing.

I'll try to reproduce it.

JJworx, thanks but I don't think a log would help me currently. With Gpg4win-3.1.3 I'm down in my main test instance to have these crashes ~0.25% (so I need around 400 verify/decrypt operations).

Cureently with the same machine using the old DLL I'm able to work with no problems. I tried several times to switch back to the new DLL and the problem appears immediatly.
If you need some other log I can produce it, just direct me. I used the procedure to enable gpgol logs I found on the forums.

Strange, this happens when Kleopatra is unable to launch the gpg.exe / gpgsm.exe binaries. But in the log I can see that gpgconf is found and scdaemon / gpg-agent seem to work. So your installation is apparently fine.

Thank you for the report. I can't reproduce this behavior of course :-/ and from a first glance I also don't see any problem in your log. The last line logged says "GpgOL code is done, handing it back to Outlook".

Thanks for your report. Also thanks for trying the beta already. I think I know why this happens. Will be fixed!

@a_p3rson : Yes. I agree that I think that cepxuo meant something differently then you.

On reviewing the bug report I realized I had included the wrong section of the Kleopatra log. I cleared the log file and ran Kleopatra again to get the correct log entry for the version of gpg4win in use. Here it is:

I think the point of my request was originally missed. I will take a screen
capture of the pinentry workflow during authentication and signing tasks -
in my opinion, they should be the same. However, during signing, the window
gets display focus (Windows switches it to the active window), whereas
during authentication it does not (and has to be alt-tabbed/switched to for
pin entry).

Andre explained that we don't do that anymore on purpose. Duck and read the discussion related to this if you are intereested. A related thing is that no-grab does not work on all platforms because it was designed for standard X but nowdays toolkits have their own ideas what is right and what is wrong.

By grabbing I mean that it's not possible to input elsewhere. Same as ssh-askpass does.

I confirm this bug!

I also have these seldom freezings. Any log / tracker I could activate that would help you?

I made a mistake and put the DLL in the wrong folder. After placing it into the correct one, everything is working fine and stable.

Yes we had a bug in 3.1.2 that when you had a contact group as recipients gpgol would silently ignore them and don't encrypt to them.

First let me say; Thank you very much for your help ! :-)

I think this might be a ticket in itself. If I send a PGP signed email to someone who then responds to me, there should ideally not be issues with it - although I think it would be important to separate which parts are signed and which are not.

header of mail forwarded. looks like it says utf-8. either way, it does work with the right key.

Received. Thanks, so this is PGP Inline. Encoding handling in PGP Inline is always "Guessing" as it is no where defined which encoding is used for the message.

I've commited a fix and because this and another issue we might do a release sooner than originally planned.

If you like you can help by confirming that it also works for you by installing 2.3.1-beta11-STABLE-BRANCH-2-3 from https://files.gpg4win.org/Beta/gpgol/ as described under: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

interesting. email sent.

Mmh no, I can't reproduce this and my initial hunch was wrong. We do in fact handle encoding in that case.