In T6883#199155, @ebo wrote:

I guess this is done if QT6 versions have a pinentry?

I guess this is done if QT6 versions have a pinentry?

This was using GCC to build, but on AIX. I believe support for dollar signs in identifiers are platform specific.

GCC allows dollars in identifier, that's the reason why we haven't encountered this issue, I suppose.

Thank you for your report.

The formatted display of the symmetric passphrase is configurable: gpg-agent.conf option pinentry-formatted-passphrase

Here we go:

Alright, my above putenv option won't work because it modifies the session environment and thus needs to be run for each gpg-agent session (connection). Adding a putenv_startrup option would help here but this way each connection could chnage the environment - also not good. In the end a way to modify the used environment variables, as you suggested, is a better way.

Yes, the workaround is to use a pinentry wrapper script that sets the value back to the correct one and then invokes the real pinentry.

Werner says this won't be fixed…
Because the system can be configured to use constraints which we can't explain except in ABNF, which won't help users.

Maybe the title should be "Password - Kleopatra" (or similar) if the operation was triggered by Kleopatra.

as far as I understand both the Gtk and Qt implementation are using pinentry_get_title which does the /proc stuff, but this is only on Linux. On Windows, pinentry_get_title will return the value set in pinentry_init, in our case pineentry-qt or pineentry-qt5.

Check out the GTK version which scans /proc for the process to find the command line. Very handy for ssh sessions.

Note that that Beta uses a 64 bit Kleopatra but the GnuPG engine was accidentally build for 32 bit. This will be fixed with the next Beta. That might increase the confusion a bit.

GpgEX requires/uses Kleopatra so that only GnuPG would be left if you could deselect Kleopatra. And that's exactly what the simple installer installs because the simple installer is included in the Gpg4win installer.

FYI usually these are my install options:

No problem. I can stay on 4.4.x. Just thought I should give the beta a try and let you guys know.

Thanks for your feedback. Maybe the "minimal" install is missing a file. It's a beta version for a reason. We'll make sure to fix it for the stable release.

None. I just use the command line tools and always perform a "minimal" install. @aheinecke: I already tested it on cmd.exe. Same result. Also I do not have QT installed, or a QT_PLUGIN_PATH set up. The bottom line for me is still:

Thank you. Fixed in: rPb415f3108921: build: Fix warning about obsolete pinentry-emacs.

What components of Gpg4win other than GnuPG do you use?

Yeah that is a messed up environment mixing elf and windows binaries. There is no which on windows. It is called where. So if your terminal is able to execute which then this is some kind of Linux environment on Windows. The winpty error comes from the terminal. Please use cmd.exe for all tests.

I just tried to call pinentry directly on Windows cmd prompt:

Thanks for the comments. This is a regular git for Windows install which afaik uses mingw64. The messup with the binaries brought in by git has always been this way. I am using aliases to differentiate between the different versions. One might think that this may cause things to break, however all used to work well with 4.x versions.

gpg: [stdin]: clear-sign failed: No pinentrysrc/libwinpty/winpty.cc, line 924

Here you are:

This issue looks still the same from the user perspective as in the task description with Gpg4win 4.4. Therefore tagging it for gpd5x

Making pinentry issue "fully canceled" if the user clicks Cancel breaks decryption of data that is encrypted with multiple keys of the owner. The user woudn't be asked for the password of their second key if they canceled the pinentry for the password of the first key.

Fixed in pinentry 1.3, when using GnuPG 2.4 or later.