Fixed now, both in the repo and on the file server. Thanks for noticing.

I really need to automate things more for a release there is just too much copy and pasting involved where mistakes can happen.

I think the problem is the following:

Fairly typical situation: user needs to encrypt binary and text regularly

I'm not really sure if "No Key" is a better string for "Ignore Recipient". But most other things are either unclear (ignore recipient) or can be misunderstood like (Do not encrypt to this recipient) as this could also mean that the recipient gets an unencrypted mail.

It now looks like this:

@dkg This patch ( rP0e2e53) might also be something for debian as it can cause crashes depending on the qt theme, which is not under our control.

Thanks!

In rGfdd1567743cc1d526f92e63162d899a24c42cdf4#61654, @gniibe wrote:

As far as I know, usually, gpg/gpgsm can assume same version of gpg-agent.

thanks for the report. I've commited a different fix 0e2e53c8987d6f236aaef515eb005e8e86397fbc which also should solve the problem.

thanks for the report and trying to help with Gpg4win. The underlying problem is that our backend (GnuPG) does not provide proper error handling when changing the expiry date. We already had an issue for that so I've merged this task with T4395.

when you double click a key and then click "Export" you get a copy & paste version of the key.

Thanks for the report. It is always good to have such issues documented.

This pretty much matches my test setup. As the crash is in GPGME it is out of Kleopatra's hand. So I'll try to write a test that repeats such a signing for lots of times. I think this is probably some random race condition.

I think that even if the reason is corrupted keys it would be good to handle this better, either in Kleopatra or in GnuPG. e.g. Kleopatra could detect if a keylisting takes too long and offer to do some cleanup programatically.

I'm also not sure how to classify this issue. I'm giving it low priority for now as we do not have the info to determine if this is a program error.

I think we had that issue in the past and solved it. It probably broke again. There is an external library we use for this dialog and that might have regressed in the latest update.

Mmh, the error log only tells me that it crashed in our GPGME library. So it is a bug in our software.

Hi Florian,

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?