I also tested it with Outlook 2010 and there this did not happen. So it's probably save to assume that this was a behavioral change in some more recent Outlook Version.

This was released 2019-06-15

Has been released and confirmed to be working.

Fix is in, will be released with 3.1.10

Fix is in. Will be released with 3.1.10

This is resolved

It turned out to be a downstream issue and the change in message class was enough from our side.

This is fixed.

This was fixed with 3.1.9

This should be fixed.

Testing with the DGN certificate showed that GPGSM returns a signature verification error (invalid digest algorithm) in this case. So the signature summary is not even checked.

Works for me! :-)

I closed this as a duplicate of a newer task because I did not find this issue when creating T4561 and there was already work done for T4561.

This issues is not really about the CRL's. GpgOL should not activate the EFail protection if a CRL check fails. That is the issue here.

One issue with this is that Qt Webengine (chrome) cannot be built with mingw. Fixing that would be a major project.

High priority and half a year no action....

back from vacation so apologies for the delay. @werner This is reproducible on the command line without Kleopatra. So maybe something for you our Gniibe to look into?

Keyserver issues are always hard to analyze because the state of the servers and which server you get is always a factor.

Sorry for the delay, I was on my summer vacation ;-)

Werner: I'm assigning this to you. Because the underlying reason is a missing status from gpg. I think we should add that for 2.3 as any new status line tends to break things.

can you please open the console (cmd.exe) and do a "gpg -K" and "gpgsm -K"

@joaociocca Can you please try to update to Gpg4win-3.1.9 and try again.

Hi,
as usual, thanks for your help.

The reason for this is the change to Kleopatra that the columns are configurable ( 4847fcc27afc8101752de82b0dd1f5fee027695d ). In the process we added additional columns like origin and to hide the "summary" column that the line edit for the recipients use we gave it an index number that was higher then our internal column count.

Thank you very much for the report. I can see this problem myself. It is strange because the code for that has not changed since 3.1.7 so it must be some sideeffect.

File->Save As now works for crypto mails. It saves the encrypted message.

This works now, the hidden BeforePrint Event enabled us to detect when a print happens and the old code to do blocking decrypts enabled the actual printing.
We also do not print "our categories" (encrypted message, level x trust),... anymore, even in quick print.

If it is that simple I really do not understand why this is not upstream. o.O

Just noticed that due to me failing to properly understand re-entrant locks the run-thread test is broken at least on windows in that it never waits for completion. So running out of filedescriptors is to expect. I'll fix the test.

My observation from running the verify threaded test on windows is that it does behave differently. The EBADF does not occur.