Case Insensitive Sorting is fixed with:
https://commits.kde.org/kleopatra/856aad228a81f542f821209ae2c796d9b7160263

Well the problem is both TCP and UDP. Somehow dirmngr tries to open a listening socket. I think that may be some feature probing in the DNS resolver. Because if the Firewall access is denied I don't see any feature loss.

The HTML in the body below the text on the GpgOL-1.4 side is a known issue of GpgOL-1.x we only added proper HTML handling with GpgOL 2.
GpgOL before 2.0 just appended the text/html mime part to the text/plain mimepart in multipart/alternative mails.

Strange, do you have any unusual Group Policies or some "Security Software" that might interfere with the running of GPA / Kleopatra (they open a local socket).

In my tests it's fixed with: b8276a4f3acecee2e467c0530007aedc9db5936a the plain text body now uses similar code to the html part. Makes sense anyway. The difference was mostly historic as GpgOL before 2.0 did not handle HTML parts at all.

If I send "Nur Text" (plaintext only) under formatting it works as expected. We query Outlook for the Body from the MAPI Data model and just get the wrong value returned. For the HTML part we use the Outlook Object Model (as we had a similar problem there that the MAPI data was not updated properly.)
The fix is obvious. We can use similar code to our handling of the HTML body. This is a workaround for an Outlook bug IMO, why should sending from drafts differ from the usual sending *sigh*

I can reproduce that problem and have opened T3614 for this.

This is the question:

Forgot to mention the revision. It's https://commits.kde.org/kleopatra/0428c744fbd56a305d3e249215d74fe6ad811acf

I implemented a text export action that uses the details of a certificate as comments. This will bring back the old copy & paste able details and has the additional advantage of a nice and quick export.

T2854 is a duplicate of this but contains more up to date information. So I'm closing this issue.

Does this still happen with gpg4win-3.0.2?

Gpg4win 3.0.2 is released which contains even more fixes for GpgOL -> Resolving this. Please let us know if you still have Problems that are not tracked here.

This works now. There is a problem still if the agent is not running with the default homedir or under other users. But this is handled in T2146

This works now. There is a problem still if the agent is not running with the default homedir or under other users. But this is handled in T2146

@werner This is sometimes still an issue. E.g. if the agent is started with a different homedir. Is it ok to just use TerminateProcess on any gpg-agent?

I'm changing this issue to resolved as I opened T3601 and T3602 for the problems mentioned in this issue. As it is better to have them separated.

I thought about (2) when implementing the new "decrypt" action in Kleopatra but we did not give it high priority as we were unsure if this is a real world problem.

sadly this happens with nearly every release that some Anti Virus software reports false positives ( https://wiki.gnupg.org/Gpg4win/AntiVirusSoftware )

*cough* That change made it into Gpg4win 3.0.2 *cough*

There is now also Gpg4win-3.0.2 with that gnupg version available.

The option now has the following logic:

• If encrypted is selected and the message is not signed.

and

• If the message has no attachments.

and

• If the option for inline sending is enabled

Resolved with gpg4win-3.0.2

The problem was with a special attachment that had no file extension. Fixed now.

I can't reproduce this with the above steps. It is sadly a known issue that moving crypto mails does not work as long as they are viewed. (T3459) But for me opening any unencrypted mail and moving it. Or first opening an encrypted mail and then moving an unencrypted mail works.

Pushed rM7b5182f28893

Fixed at last.

Added it. For now it's pretty bare but already an improvement on the old (which only showed "class") and no indication if a signature was revoked.

Prio low, as I noticed that Kleopatra already had some code in there to merge a secret with a public key in a keylisting. This can be used for me.

I looked into it. The problem is that attachments are opened as "Read Only" so we can't change the message class or handle it ourself. Once opened there is no apparent way to change the message to read only. Only if the message containing the attachment is marked as modifyable:

I tried to reproduce this with current GpgOL and it just worked. Even if I connected Enigmail to Exchange (Outlook.com).

With Gpg4win 3.0 we registered associations for S/MIME and OpenPGP Files:

I just tested with intevation's CA on Windows and it works. It also worked with our test.ca in the base test before the 3.0.1 release. I think this is resolved.

We now check for an error of the gnupg-w32 installation (which should not happen normally) and show a Message Box on error.

It's also fixed. There was a problem with the error handing. A canceled pinentry is communicated as an error with code operation canceled.

As a note: The second crash might be related in that the crash could happen on any error. So if the user had a "real" error it might have crashed instead of showing the error.

Indeed easily reproducible issue.

Looks good. With the libassuan-hang-test.diff and D455 D456 applied on current master branches it no longer hangs. It hung with only the libassuan-hang-test.diff.

Tested it on Windows, with the sleep test patch in Libassuan it does not hang anymore when it hanged without this change.