Thanks for reply and clarification, regards danny

Thank you for the report. Sadly this is a long standing bug that is still not fixed. We hope to address this in a future version.

Even with the logging changes this still happens. I just retested it. Can't run Kleopatra on Linux with GPGME_DEBUG=9.

The explicit check for a valid FD (in select) I mentioned above is commit 8173c4f1f8a145c4b1d454f6f05e26950e23d675

It is propably related to decrypting large (single) tar-files. It works flawlessly when renaming the tar-files to another extension before encrypting and afterwards decrypting it again. But as long as it is named xyz.tar Kleopatra crashes. Could it be that untarring causes some "out of memory" failure? I recognized that while decrypting the tar there was no sign that the decryption process would allocate any disk space. There is just an empty randomly named folder being created upon decryption.

Dear aheinecke,

Hi Adam,

I think it has something to do with the number of files. Just encrypting / decrypting a 10GB random data file did not show a problem.

The self test error message looks like it originates from https://github.com/KDE/kleopatra/blob/master/src/selftest/enginecheck.cpp

gpg -k works and displays the list of keys I expect. gpgsm -k returns nothing.

Strange, this happens when Kleopatra is unable to launch the gpg.exe / gpgsm.exe binaries. But in the log I can see that gpgconf is found and scdaemon / gpg-agent seem to work. So your installation is apparently fine.

On reviewing the bug report I realized I had included the wrong section of the Kleopatra log. I cleared the log file and ran Kleopatra again to get the correct log entry for the version of gpg4win in use. Here it is:

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Problems here are:

• The icon theme needs a build tool to generate which is a problem with CMake Crosscompiling.
• Building natively and then packaging the icontheme.rcc would work
  • The breeze-icons.rcc must be renamed to icontheme.rcc and copied to <instdir>\bin\data
  • index.theme must be in the same place.
• The GpgOLGui would not find icons from that because it would need to link to kicontheme.
• The Kleopatra icon in breeze would need to be patched out as we want to use the old icon for kleopatra.

We have debug output now to show which commands are running.

We have a progress dialog now and only show details on request. I've also fixed a bug that you could trigger learning the keys twice which lead to undefined behavior.

This happens only if GPGME_DEBUG is set to 9 which was accidentally set in my environment. So I've lowered the priority.

FWIW, we record the origin of the keys. So you have the information. Use --with-key-origin in a key listing. GPGME also has the info.

Indeed. Thanks for the reminder.
There is some code currently in there already but its not yet fully implemented. Needs to be finished.

Deleting a user id is more or less useless. What you want is to revoke a user id.

I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.

Tester reports that this works now.

This was a misunderstanding. Import is possible. The german translation of Kleopatra wrongly indicated an error because it translated "unknown certificates" as "ungültige Zertifikate".

On another note. We might also want to reduce the clicks required when certifying a key. The "I have checked the fingerprint" checkbox is out of time. People will check it regardless and we can't force them to do it.

Finally changed it. Especially for keyserver search this was important.

I'm going for Wontfix here. It's just too verbose and I don't really see the point of that additional information.

Now we have this:

We have two cases:

1. No MDC with a "modern" cipher algo