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.

Thank you. Applied.

Tested on Linux, modern Windows and Windows 10 2016.

Noteworthy changes in version 1.3.1 (2024-07-03)

is there a keyring/password manager that is not dependent on a desktop environment that the terminal pinentry supports?

Different pinentries provide different options. The curses pinentry does not have that external password manager thingy. Mixing GUI and tty use seems to be a rare case.

Verified in pinentry-1.3.0.

Fixed in pinentry 1.3.0.

This was done by Tobias.

For the reference, for now i just did the dummy install in the Fedora spec file:

Tobias, if you find some time, can you please see how this can be done.

Thank you!

See T7046 for the release info. Note that the mentioned fix for kwallet already landed.

Noteworthy changes in version 1.2.1 (2022-08-24)

I still need to land the fix for the kwallet problem, but that can be done first thing monday so nothing that really blocks a release

I had a look at the open tasks for pinentry(-qt) and didn't see anything that we should address before doing a release. @werner?

I should say: I can ship a snapshot in Gentoo if that's okay, but I'd prefer not to.

Lowering priority because it does not seem to be a popular issue.

This is still an issue.

Thanks for the contribution, sorry this took us a while to get to. I've merged your changes to the pinentry repo now.

Still no response after more than 2 years?

Thanks for the reviews. And your beautiful work, by which I also mean the response to the feedback and how you managed to work with phabricator. I will commit the patch on your behalf then later.

I think that tried_password_cache in the documentation is wrong. The text:

and @code{tried_password_cache} is false

Thanks for the update.

In general, the changes look good.