This has been implemented.

I've started some documentation how to repair a broken archive under: https://wiki.gnupg.org/TroubleShooting#Restoring_corrupted_Archives_created_by_Kleopatra

If the filename embedded in the encrypted message differs from the filename Kleopatra uses (which is derived from the file system filename) Kleopatra will now show the filename. This should cover the case where users receive an "Attachment.pgp" and do not know what that is.

Could it be that you are running into: T4347 ? Maybe this will just be fixed for you then in the next version.

@nbriggs No this is not related if you get "no pinentry" it means pinentry is not started at all. This issue is about pinentry starting but not properly coming to the foreground. I've opened T4430 for your issue.

Hi,
I'm pretty sure that I finally understood it and fixed it. There was a data mismatch between the IMAPISecureMessage and IMAPIMessage which somehow only happened for sent mails. This case is now handled.

There was indeed a problem. With a test card I could reproduce the issue and fix it.

I'm changing this to testing as the original problem is now fixed with a good solution that properly detects the contents of ms-tnef wrapped messages.

b8d651c4d083d2295cdd75e9f5882ab36ef8f418 Fixes this issue.

Can you open the command line (cmd.exe) and execute there: "gpg --passwd 6B05B09F" ?

The step where it is hanging at is to register the GpgOL Addin with Windows.

Thanks for the confirmation. Although I still don't really know how to fix it :-(

We are aiming for this week.

@dkg If you propose a patch here I'm pretty sure that we will accept it. As one of our Python binding users you know better then us how the API should behave.

see: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

This is very strange, common to all the crashes in the log is that they happen while a keylisting is running and before the first key from that keylisting is returned. But this could be a red herring because the keylisting is always started immediately in a background thread and so it would be normal that if the crash occurs immediately that it would still be running. The keylisting code is extremely similar to Kleopatra though. So I don't understand why Kleopatra would then work for you.

Thanks! I've confirmed that it works for me.

Thanks for the report. Log looks not unusual.

I think that this might have the same underlying reason as the fixed T4321 (still open because it was not yet released).

Just for history if I ever need it again here is a patch I wrote debugging QIODeviceDataprovider. I have not commited it for fear of regressions and apparently the code is correct for Linux and that it did not work as expected on Windows had other reasons.

After further debugging it showed that it had to be an issue in how we use QProcess. So I've rewritten the way we call gpgtar on Windows and replaced it with a simple anonymous pipe solution. I've tested more then ten times with various directories that the data corruption no longer occurs.
The performance is slightly better, but we still use GPGME so it's not as good as if we would pipe it directly. But not using GPGME was not really an option because otherwise I would have had to implement a full blown "how to call gpg" with error handling etc. for Kleopatra and I really did not want that.