To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.

In my debian buster pbuilder enviornment I got the following failure when packaging master (beta195):

Gpg4win-3.1.8 was released.

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.