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.

I pushed the fix. Thanks for your cooperation.

Thanks for further testing.
I realized that it's not the left border drawing problem in fact, but the newline should be between the description and passphrase line.
I'm going to fix this.

Thanks for the further fix! With that only a minor hiccup remains:

Thanks for the update! With git-master, the toy example above works fine. However, pinentry-curses seems to hang with real commands from gpg. Here is an example:

$ ./curses/pinentry-curses 
OK Pleased to meet you
SETDESC 請輸入密語來解鎖 OpenPGP 私鑰:%0A%22Chih-Hsuan Yen <yan12125@gmail.com>%22%0A3072 位元長的 DSA 金鑰, ID F98EF2A7B0A098AE,%0A建立於 2018-04-25 (主要金鑰 ID 3FDDD575826C5C30).%0A
OK
SETPROMPT 密語:
OK
GETPIN

(CPU usage of ./curses/pinentry-curses goes > 90%)

I pushed the change to master.
Please test.

Well in my browser (Firefox) the dialogs are not rendered correctly. Here are the two dialogs in the terminal:

Thanks for the feedback, @werner. I think I understand the reasons that we've gotten to this place -- but that doesn't mean i think it's ok to stay here. In this bug report, i'm pointing out that the documentation and the feedback/error reporting is misleading, which leads to difficulty in debugging. We need to do something about it.

pinentry-gnome has no grab support. However, it needs to accept that option so that gpg-agent does not error out. We want to have the same global options for all pinentries. Whether they work depends on the pinentry and other parameters. For example when falling back to curses grab won't work in any pinentry.

I note that this is likely happening because we are using gcr's system-modal prompter. I haven't looked into whether it's even possible to use gcr in a non-system-modal way, but i'd welcome pointers.

No worries -- you led me in the direction of a solution when you mentioned loopback mode. I appreciate your time and your help!

Sorry, I responded in a mode of "tracking a bug to fix soonish". I should have changed my mode into showing HOWTO.
Thanks for sharing useful link.

I found these instructions for pinentry loopback in Emacs, and they worked!

When you can configure it properly, there is a way to workaround it.

For (1): it is broken out-of-the-box, that would be true. When you can configure it properly, there is a way to workaround it. Well, I admit, it's not yet perfect.

Thank you for that analysis. I don't understand some of the parts (because I don't know anything about pinentry), but I do have some questions.

Thanks for your report. The symptom you have could be only solved by using pinentry loopback mode, or using some special pinentry for CLI, I suppose. pinentry-tty is not sufficient for this usage.

Please let me know if I can run any other tests to help debug this issue. I'm happy to help.

I should add that using gpg on the command line works fine over SSH. The problem occurs only inside Emacs over SSH.

Ah, I added the --verbose option and got this output (sanitized by me):

Sorry, I forgot to mention it. You need to add -v to the command line.

Thank you, werner. Could you please tell me an exact GPG command to do this signing, and tell me where the output line should appear? I tried this command on the command line:

Which pinentry are you using in in what mode? Please do a sign operation and watch out for a line similar to:

This is known and by design, basically it is a legacy X feature. For Wayland, the window manager determines if a window should be blocking, no grab or grab, not anything applications themselves have control over. This came up many times when I was first making the interfaces. You can reference these two comments, but there are many more in between them.