You are right. I originally left it open because it was in a different language but the first report. But it's cleaner to close it as a duplicate, also.

T4129 is also a duplicate.

Maybe not on Linux but the environment is visible from other processes in the same way as the command line. So I don't see why we should add yet more clumsy passphrase workarounds to gpg. We already have PINENTRY_USER_DATA which can fulfill the same task.

Thanks for the report. This was already reported andf fixed. We are aiming for a new Gpg4win / GpgOL Bugfix release soon to address this and other regressions.

i note that my patch doesn't include an addition to the test suite, which it probably should, though i'm not fluent in gpgscm. if someone could update it to include a test, i'd appreciate that, and would probably learn from the commit. I imagine the test would do something like:

I tried to push commit 07c19981da0607dc442fadc4079b1d71fbef8f83 to branch dkg/passphrase-env on playfair, but i got this complaint:

I made a large file for testing, but it doesn't matter. There's an arbitrary parallel limit where gpg will crash.

This issue prevents a user from accessing any other window on their system while the pinentry prompt is up. This issue is different than T2145. This issue is explicitly about the system-wide nature of the modal. The other issue is about auto-typing from a password manager.

Please see my comment on T4152.

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.

updated example sent.

I confirm I have the same problem but, unfortunately, the beta did not help.

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.

JJworx, thanks but I don't think a log would help me currently. With Gpg4win-3.1.3 I'm down in my main test instance to have these crashes ~0.25% (so I need around 400 verify/decrypt operations).

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".

Thanks for your report. Also thanks for trying the beta already. I think I know why this happens. Will be fixed!

@a_p3rson : Yes. I agree that I think that cepxuo meant something differently then you.

Could you say, on which platforms exactly it should work?

Yes, due it uses adwaita-qt theme.
Yes, I can start it on the command line and it works, but gives a warning.

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
pin entry).

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.

no-grab does only work on certain platforms. Thus this is no bug.

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.

for comparison pinentry-qt doesn't ignore env:

"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.

I don't know about gpg-agent, but pinentry-gnome3 ignores $GTK_THEME (and $GDK_SCALE) even if I run it directly:

$GTK_THEME=Adwaita:dark GDK_SCALE=2 /usr/bin/pinentry-gnome3
OK Pleased to meet you
GETPIN

We need a way to replicate your problem, a few questions first:

I would call that a feature because it makes sure that the Pinentry always shows up the same regardless of an application selects a different theme.

We know that. And pinentry-gtk does like that.

It's possibe to do via gtk3 directly:
https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-device-grab-add

Yes. It's up to GCR library in GNOME.

By grabbing I mean that it's not possible to input elsewhere. Same as ssh-askpass does.

By grabbing I mean that it's not possible to input elsewhere. Same as ssh-askpass does.

I confirm this bug!

@werner Given you filed it as low priority and documentation - could you give feedback on whether that is expected behaviour or not?