Got it. This was a bug that was around for ages but only started to occur in the verificationresult when we started in 3.0 to show the KeyID / Options for the unknown certificates.

Again, thanks for your time testing it again.

1. it is reproducible
2. Kleopatra crashes at the end of the verification of a signature
3. it is a openPGP signature
4. please see first picture
5. I have only openPGP certificates in Kleopatra

Thanks for trying out the beta and your report.

This was fixed. The check for VS-NfD mode was crashing.

Thanks for your report. This has been fixed for the next version ( https://bugs.kde.org/show_bug.cgi?id=391222 )

The second user ID in my test case was an "URL". So we now use what ever the "raw" user id data is as the Name if both name and email are empty.

I don't find an easy way to fix this.

The field is now renamed to "Activate GnuPG Profile" to make it more clear the the button activates a new profile.

I've added this to libkleo formatting now. But seeing it and thinking more about it I don't like it. As I think that the export is mostly for "You give this to others" information about the subkeys is too verbose. The current header should suffice as "some info for differentiating between keys".

Kleopatra now shows this:

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):