As far as I know this works.

This works but might have created a regression which is tracked in T4701

I give this normal priority even if it is a whish because I have the same whish and already have some code around that would make it more comfortable, especially if it is used directly in GpgOL.

I still would like to test this some more and work on it. I think the implemnation might still be a bit fragile.

I'll try to look at it this week. Apologies for the delay with this.

Mmh, No Data usually means that our parser had a hickup. I'll look at your examples.

Mmh, No Data usually means that our parser had a hickup. I'll look at your examples.

Strange. Can you please go to the command line (cmd.exe) and run gpg --verify "c:\<path to>\gpg4win-3.1.10.exe.sig" "c:\<path to>\gpg4win-3.1.10.exe.sig"

can you hover over the GpgOL Icon and look at the tooltip? Maybe there was an error during validation.

Account disabled and I'm closing this as resolved.

Thanks for reporting this! I've added it to our list of know problematic Addins. https://wiki.gnupg.org/GpgOL/IncompatibleAddons#Mimecast_for_Outlook

I've sent multiple PGP/MIME mails in various formats to a protonmail developer and all worked fine. So we have confirmed that protonmail and GpgOL are generally compatible.

I've sent a mail to a protonmail dev asking if protonmail supports PGP/MIME.

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,