a GUI for GNU PG among other things
Tue, Feb 5
This was fixed.
Jan 16 2019
Jan 14 2019
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.
Jan 11 2019
Dec 17 2018
Even with the logging changes this still happens. I just retested it. Can't run Kleopatra on Linux with GPGME_DEBUG=9.
Nov 26 2018
Nov 19 2018
Nov 14 2018
Nov 12 2018
Oct 31 2018
The explicit check for a valid FD (in select) I mentioned above is commit 8173c4f1f8a145c4b1d454f6f05e26950e23d675
Oct 24 2018
Oct 21 2018
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.
Oct 18 2018
Oct 17 2018
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.
Oct 16 2018
Oct 15 2018
Oct 1 2018
Sep 19 2018
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.
Sep 18 2018
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: