I am always glad to fix such bugs before a release (I am about to prepare 2.2.22).

I am always glad to fix such bugs before a release (I am about to prepare 2.2.22).

It worked! You were right!

Thank you for your prompt help. It's much appreciated.

rG4c8d5eb0bdd3: agent: Allow TERM="".

I see. Thank you @werner . For clarity could you please link the patch that was not backported to 2.2.?

Mails crossed ;-)

But @werner what's the value $TERM *supposed* to have? When gpg is invoked straight by Gnome? I can run the command sh -c 'env | grep TERM > ~/gnome-term.env' in Gnome's "Run Command: interface and then the file ~/gnome-term.env says TERM is set to nothing (It is set, but the contents is a "" string).

Ah wait. This has been fixed in master a year ago but was not backported to 2.2; see T4137. I'll add it to the forthcoming 2.2.22. Thanks for the report.

The warning above is harmless. Both strings are actually the same but stem from different versions of the autotools helper scripts

Unfortunately I've had some trouble compiling the latest git version of GnuPG for NixOS - I got this warning which turned out to be a blocker:

Without really looking at your report: May it be that this is because Pinentry does not get the WAYLAND_DISPLAY variable as reported in T5016? This will be fixed in 2.2.22 which I hope to release this week.

I take some of my words back - using or not using MOZ_ENABLE_WAYLAND=1 doesn't make a difference eventually - If Firefox is launched by Gnome and not gnome-terminal, pinentry fails to launch with and without MOZ_ENABLE_WAYLAND.

To explain the use case, I've started coming up with a good passphrase and this took a bit of time with a pencil and paper in front of me. When I wanted to type it in, it was too late. Thus I guess that some people will look up good rules of passphrases or at least make sure they can remember the one they are typing in.

5 or 10 minutes are not reasonable in this case. Users are expected to attend the key generation. Your idea of having a countdown after, say 30 seconds, makes sense and should be easy to implement in the pinentries.

@aheinecke thanks for commenting.

I can reproduce this.

I keep it open as testing so that we keep it in mind for a release.

There was a patch for this by david faure which added an
#undef ttytype after including curses.h

I debugged some more.

It is the pinentry-curses, which is needed to reproduce the problem.
Using tab and Return to navigate the dialog.
After pressing ok, the password question dialog reappears. I tried 20 times to press ok, every time the password question dialog reappeared.
If I press cancel, the process aborts. So I'm sure, I hit the right button.

And yes: If I install pinentry-gtk2 and follow the steps, it works as excepted.

Perhaps I explain the steps, I'm doing.
I'm on a minimal debian buster instance.

1. gpg2 --full-gen-key
2. Insert stuff.
3. See Dialog:

Real name: Test1 Tester
Email address: test1@example.com
Comment: no pw
You selected this USER-ID:

"Test1 Tester (no pw) <test1@example.com>"

Ok. Renamed ist "ttytype_l" (l for local) and found the button to upload a file.
Hope it helps.

Using a double underscore in a symbol should be avoided because such symbols are reserved for system use.
(To include a diff inline, please intend it by two spaces so that it is not not considered as marked up text.)

I just tried and Pinentry ask me whether I really want to use an unprotected key. Take care that you hit the right button.

Yeah, this can be done.

Reported.

You may.. Comments were relevant. Bye.

FWIW, the GTK and QT pinentries do have a qualitybar. However is is only enabled:

In T4809#131931, @werner wrote:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

@Rycky_Tigg cases 1, 2, and 3 that you document here each show the behavior that i would expect from pinentry-gnome3, given the definition of its Assuan-based API and its use of gcr-prompter. (i'm assuming that in case 3 the user just waited longer than the allowed timeout)

"more specific about what you think is wrong"; From https://bugs.kde.org/show_bug.cgi?id=412569 copied)/pasted:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

pinentry-gnome uses gcr's gcr_prompt_set_password_new to prompt for a new password, and ignores the SETQUALITYBAR assuan command.

It seems that gnome-keyring-daemon has some incompatible changes which breaks that version of pinentry-gnome. Or GKR has not been setup properly. I'd suggest to use pinentry-gtk until folks with knowledge about Gnome folks have figured out what is going wrong.

Hey. As reference – Complete set of features while run in Windows.

Please describe which features are missing.

I believe the problem was fixed in the master of pinentry with newer gpg-error-config and libassuan-config which support cross build better.

Confirmed that the support of --no-global-grab doesn't work well.

Thanks for the follow-up Werner.

Then better do not use a curses pinentry. It can't guarantee that another process changes the tty properties. For security reasons it is better to run the pinentry in a different window (ie. a GUI based pinentry).

It is not just about being annoying but for security reasons. It would be too easy for other applications *think webbrowser or Acrobat) to take a screenshot and pop up a modified version of that screenshot with data entries to act as a MitM.

The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.

reviewing this, i think the situation is:

I think the problem is the following:

False alarm. Turns out pinentry-gtk-2.exe is also not working all the time.

@bb - I've tried this, this doesn't appear to work. It looks like the Gtk2 pinentry doesn't grab focus when doing authentication, either. Interestingly enough, it also doesn't show in the taskbar.

Note:
I added:

pinentry-program "C:\Program Files (x86)\Gpg4win\bin\pinentry-gtk-2.exe"

as a workaround to my gpg-agent.conf. This pinentry is able to grab the focus.

Does anyone has an update on this issue?

I've just uploaded pinentry 1.1.0-3 to debian unstable with this fix in it.

@aheinecke thanks for the heads-up. i'll pull this in.

@dkg This patch ( rP0e2e53) might also be something for debian as it can cause crashes depending on the qt theme, which is not under our control.

Thanks!

I can confirm that the patch from the referenced commit fixes the issue. Thanks for the quick action!

thanks for the report. I've commited a different fix 0e2e53c8987d6f236aaef515eb005e8e86397fbc which also should solve the problem.

Adding the patch here.

Thanks for all the fixes! I can confirm commit dad35d65f05eb1c15589a7e4755dcae6aed2d6cf works just fine on all my machines (Linux & macOS).

gpg-agent side is fixed to relax the error handling.