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.

I'm using the standard pinentry provided by Homebrew: https://formulae.brew.sh/formula/pinentry#default

gpg -v -K does not require a pinentry. You can check this by adding debug-pinentry and log-file /some/file to the gpg-agent.conf - you should not see any pinentry invocation.

We should not backport this to 2.2; better update to the current stable version (2.4)

Using Ubuntu, it's GnuPG 2.2 (which doesn't have the fix of T4585). Without the fix, killing gpg (by CTRL-C) causes problematic situation where pinentry remains asking.
That's because gpg-agent and pinentry don't know the frontend side has been killed. T4585 introduced a watching thread into gpg-agent, so that it can correctly detect lost of frontend.

Hi @gniibe - thanks for your fix.

Pushed the fix for SIGINT handling of pinentry-tty and pinentry-curses by: rPa6f63fe37dbf: tty,curses: Upon SIGINT, let pinentry exit gracefully.
This fix should improve the situation.

Thank you for the report.
I found a bug in pinentry-curses and pinentry-tty for handling SIGINT. I am going to fix this.

In T6085#162923, @ikloecker wrote:

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

Autogeneration isn't viable if an organization has stupid password constraints that the autogenerated passwords do not satisfy. In particular, the autogenerated passwords do not contain any non-alphanumeric characters, but many password policies require such a character.

I have set T6513: Kleopatra: Require GpgME 1.21 as blocker for this issue because, in my opinion, showing the above mentioned "Operation fully cancelled" error message is from a user perspective worse than showing multiple password prompts.

Setting close_button when the user rejected the pin entry (by pressing the close button, the Cancel button or Esc) causes fully canceled. Unfortunately, Kleopatra (and in fact GpgME::Error) has no idea that fully canceled should be treated as canceled and not as error. Therefore, Kleopatra shows an ugly error message:

An error occurred while trying to change the passphrase for [...]:
Operation fully cancelled

I see the problem: The Qt Pinentry does not implement the BUTTON_INFO status and thus we don't get a fully canceled error back (gpg-agent maps the cancel error to fully-cancel if the close button was used). Should be easy to fix in pinentry (set pinentry->close_button in the close eventhandler).

Thank you, your suggestion inspired me to experiment a bit further and I found the problem - I needed in fact to delete the line from my ssh config, no idea why:

Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

Now I update startup tty only on terminal start and it seems to be working. Still a bit strange.

On a terminal, please invoke:
$ gpg-connect-agent UPDATESTARTUPTTY /bye