Running with -v would really be helpful.
This was a regression from 59e8a7ee3bcd16275091c9535626e49fc2a6c4af where a performance improvement to cache an object caused this problem.
Ah wait, I just remembered T4142. Maybe that is related. I'll try to reproduce that one first.
Again one of these issues I can't reproduce :-/
Mon, Sep 24
Sat, Sep 22
I made a large file for testing, but it doesn't matter. There's an arbitrary parallel limit where gpg will crash.
Please check again with a recent upstream release or report to Debian. The release from Debian is pretty old and has a couple of non-standard patches.
Fri, Sep 21
updated example sent.
Thu, Sep 20
I confirm I have the same problem but, unfortunately, the beta did not help.
Wed, Sep 19
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.
I'll try to reproduce it.
Cureently with the same machine using the old DLL I'm able to work with no problems. I tried several times to switch back to the new DLL and the problem appears immediatly.
If you need some other log I can produce it, just direct me. I used the procedure to enable gpgol logs I found on the forums.
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.
Thank you for the report. I can't reproduce this behavior of course :-/ and from a first glance I also don't see any problem in your log. The last line logged says "GpgOL code is done, handing it back to Outlook".
@a_p3rson : Yes. I agree that I think that cepxuo meant something differently then you.
Yes, due it uses adwaita-qt theme.
Yes, I can start it on the command line and it works, but gives a warning.
Tue, Sep 18
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:
I think the point of my request was originally missed. I will take a screen
capture of the pinentry workflow during authentication and signing tasks -
in my opinion, they should be the same. However, during signing, the window
gets display focus (Windows switches it to the active window), whereas
during authentication it does not (and has to be alt-tabbed/switched to for
Andre explained that we don't do that anymore on purpose. Duck and read the discussion related to this if you are intereested. A related thing is that no-grab does not work on all platforms because it was designed for standard X but nowdays toolkits have their own ideas what is right and what is wrong.
pinentry-qt giving Gtk- warnings? Very strange. Please give an example. You can start pinentry on the command line like
if you start gpg-agent in that deprecated way it sees the envvars. it will even see them if it is as suggested started on-demand by gpg. However, things are different when a gpg-agent is already running; in that case only the listed envvars are conveyed to the pinentry.
It's white due to https://dev.gnupg.org/T4144
Moreover, pinentry-qt doesn't ignore env if it runned from gpg-agent. So you are wrong about technical reason.
"partially" means it doesn't allow to input elsewhere, but in case of focus loose input will go nowhere
At least it MUST NOT grub input with no-grab option. But it doesn't allow to input elsewhere in any case.
We need a way to replicate your problem, a few questions first:
We know that. And pinentry-gtk does like that.
It's possibe to do via gtk3 directly:
Yes. It's up to GCR library in GNOME.