Cancel is now handled and the key is not removed if the user canceled.

With the tab layout I think that this is resolved.

This is fixed by no longer using kleopatra for this ( T3509 )

Leaving this open until we have a new version of GnuPG in the installer. While Kleopatra should no longer crash it won't properly work without the patch to GnuPG.

Got confirmation In Bugs.kde.org that this is fixed https://bugs.kde.org/show_bug.cgi?id=389792 as my tests also showed this -> resolved.

We have this now. There might be bugs but in general this works.

Yes sorry, I decided against a release specially for that is it is not super critical, no data loss.

A beta of the next version where this is fixed is available now: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe

When we detect GnuPG > Version 2.1.15 Kleopatra now offers (and has it as default for ECC) to use cv25519 / EdDSA

It looks like you're having the same issue that I reported: T3761.

Hey, @uwestoehr. It looks like you're having the same issue that I reported: T3761.

rW981a6fae5355 Fixes the problem with Kleopatra's config files.

With the attached commit gpgconf works. Key generation in Kleopatra also handles the case now that gpgconf does not work.

The underlying problem is that gpgconf does not work in such an environment.

This is coming along nicely. It might take longer then with Kleopatra if the key is large (as the new resolver does a full keylisting on every start) but that should be OK and we have plans to optimize that anyway.

Steps 1. and 2. are now implemented in the async-enc branch of GpgOL. The keyresolver patches are updated for me and partially commited.

Ah under Linux we ran into an assert which made finding the problem easy. The bug was introduced by the fix for T3602. Will be fixed in the next release. Apologies for the inconvenience.

Thanks for your report. I tried this several times. Could not reproduce it at first but I could get it to crash sometimes. Even without GpgEX just by double clicking the signature file.

Confirming this bug in Gpg4win version 3.0.3 (previous version was OK).

1. Collect all data in OOM, then start a thread to do the encryption.
2. Do a proof of concept that this actually works and outlook lets us do it with our usual window message async handling.
3. Update my Keyresolver patches in Libkleo and build a "libkleo-tool" to do the key resolving.
4. Figure out Window Management / Create a Qt Overlay over the Mail window to block it from closing while encryption happens. This will resolve all bugs related to window mangement of the current key resolution.

In T3714#109752, @werner wrote:

I have not checked whether we make this available in the GPGME API

There can't be an MDC warning if MDC is not used ;-)

As far as I can see GnuPG does not emit appropriate status lines:

The status is now shown and updated.

No longer blocks with that commit. Keylistjob is started in the background. As long as the keylistjob is running the validity is shown as "Updating..."

Implemented with: https://commits.kde.org/kleopatra/9d1ebcb1e5f6b44a745c7e947f2e8eaf88fff786

I believe that this was fixed in T3658 which reported more clearly what was attempted to verify and what failed.

Indeed, thanks for the note. I added the variable only later on for the check of protocol unknown and overlooked to update the setProtocol call.
I've updated the code accordingly.

@aheinecke thanks for the fix. But I have a suggestion for the code(I only looked at the diff):

Fixed with https://commits.kde.org/kleopatra/066c6e4ca82d064437f1902838d09fa903147e40

In the folder %APPDATA%\gnupg create a file named gpg.conf (or edit it if it exists) and put the line "ignore-mdc-error" in there. This should globally set this option and gpgol will also respect this.

Thank you for your report. I can reproduce this problem. Kleopatra correctly looks for the signature file but then fails to set the protocol. This results in an internal error.

In T3714#109045, @Lloyd wrote:

I appreciate the dangers. Whilst I try and persuade the sender to deal with the issue at their end, is there anyway to include this option in GpgOL on a temporary basis?

Andre, I assign this to you. If you don't think that a better warning in Kleopatra is needed, please close the report.

OK. Thank you for that.

Thanks for asking. We may need to put this into the FAQ, so here is my answer:

Forgive me if I'm completely off the mark here. In no way do I claim to fully understand gpg etc.

The last line shows that gpg decided that to return a failure because the message does not use the MDC scheme. Since the introduction of modern algorithms with a _blocklength_ of 128 bit (e.g. AES) gpg always uses the MDC encryption system even if it is not announced by the respective key flags. The reason for theses algorithms are newer than the MDC system and thus we can expect that all applications supporting AES will also support MDC.

Fixed with: https://commits.kde.org/kleopatra/c85bc8ebbe8594be9309e3e8a0945a5dbb90828c

Also the Name and E-Mail split in the table looks ugly. While technically they are on different UserID objects it would be prettyer to combine them.

This goes to wontfix I investigated and there is no way to attach a file trough the mailto protocol with outlook. Only the parameters from https://msdn.microsoft.com/en-us/library/aa767737.aspx are supported.
Theoretically Kleopatra "could" use MAPI to achieve creating a mail with attachment but this would be overkill. Kleopatra puts up a big warning that attaching may not have worked and ok.

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

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.

I checked the mingw runtime and did not found any allocation of a new console. Thus I don't understand why a console pops up when gpgconf is used. gpgconf spawns gpg et. al to read its options and it does this without using DETACHED_PROCESS. Thus all these subprocesses inherit the parents console - which is for gpgme started process no console (due to DETACHED_PROCESS used in gpgme_w32spwn). For a GUI application like Kleopatra which has no console, the use use DETACHED_PROCESS sould not make a difference because there is no console to inherit. Andre's test however show that it makes a difference.

The assuan_pipe_connect function is called with bit 7 set for example to start pinentry or scdaemon: