At least it MUST NOT grub input with no-grab option. But it doesn't allow to input elsewhere in any case.

I don't know about gpg-agent, but pinentry-gnome3 ignores $GTK_THEME (and $GDK_SCALE) even if I run it directly:

$GTK_THEME=Adwaita:dark GDK_SCALE=2 /usr/bin/pinentry-gnome3
OK Pleased to meet you
GETPIN

I would call that a feature because it makes sure that the Pinentry always shows up the same regardless of an application selects a different theme.

We know that. And pinentry-gtk does like that.

It's possibe to do via gtk3 directly:
https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-device-grab-add

Yes. It's up to GCR library in GNOME.

By grabbing I mean that it's not possible to input elsewhere. Same as ssh-askpass does.

By grabbing I mean that it's not possible to input elsewhere. Same as ssh-askpass does.

I confirm this bug!

Well, the counterpart in gpg-agent is missing.

By grabbing I guess you mean that the cursor / keyboard input is automatically focused on the input field? I also noticed that this sometimes does not work well.

I'm seeing this as resolved. It's a design decision by the pinentry-gtk maintainer. pinentry-qt is the default pinentry for windows and there pasting works, as you have confirmed.

Thanks. I added all standard names to that list.

@gouttegd Thank you very much!

Following in-person discussion with @werner last week, I have now added this EFL pinentry to the master branch of pinentry (commit 948105b).

Thanks for the quick reply @aheinecke.

I (as the maintainer of pinentry-qt) fully agree with your sentiment. I changed it in pinentry-qt (since version 1.0.0) so that the keyboard input is only grabbed (which is a security feature) when the input focus is on the passphrase entry as I found it very annoying myself.

Then please set DISPLAY ;-)

Just tested 1.1.0 - no difference. BTW, check references issues, they contain strace output and mention why this happens: dropped root capabilities to ignore file permissions.

Would you be able to test with pinentry 1.1.0 which has a few things to make debugging easier and is also what I am testing against. To check what permissions are wronf I would suggest to run under strace.

When a command is invoked from Midnight Commander, pseudo tty is used.
You can confirm that by typing tty and see the output of the command after exiting from mc and again typing tty.

Installed pinentry version is:

No clue what their problem is, I have a few projects scanned by Coverity. Most are forks that I took over, but one is not really. Not sure why they took such issues here.

Okay. Thanks for the report. I once looked at Coverty but decided not to use it because of their rules which would not allow me to document and fix a possible security vulnerability without following their process. If there is a security problem I will fix it according to my schedule and not allow anyone to delay it.

After fighting with Coverity over a fork of pinentry that has EFL. I setup to have Coverity scan. Which found some like 22 defects. Coverity unable to identify that I have any affiliation, after I spent/wasted hours getting a build to upload to Coverity to scan. Just to fight with some unhelpful person basically standing in the way of FOSS project, a wonderful Mel Llaguno. Decided for security reasons I be denied ability to use Coverity to scan pinentry for defects, even in the EFL interface I made and am the author of. Which also means I cannot fix other issues with pinentry or aide further in development....

Your welcome, I can remake another unified patch if need be. I was starting to prepare things to be a stand alone fork. Did an initial .travis.yml file, and initial stuff for Coverity. Though never did get a build uploaded to Coverity. Not sure if you have ever run pinentry through Coverity or other GnuPG stuff, may be a good idea just to see if it catches anything.

Thanks for the long explanation. I think it should go into pinentry proper. I will have a closer look on it.

@werner no problem with re-opening. I closed as it seemed it was not of interest or wanted. I wasn't get any responses like asking why it was left out of 1.1.0 release. To my knowledge other than preferences of GnuPG devs, changes to suit your needs, grabbing, libsecret, etc. It should be good to go without any issues. Thus I was waiting next release, assuming it was already committed . May have confused it with some other PR that was committed. But there should not be any outstanding issues preventing it from inclusion. If there are it was never relayed to me. It should be ready for inclusion, less any requested changes.

@werner no clue, I thought it was merged in at some point. I could have sworn something happened there. I went on advising others like the TQT interface assuming EFL was already added. I was shocked it was not when release came out and no explanation as to why it was excluded.

Oh yes, I should re-open this because we should keep on tracking the status - either for an included EFL version or an external version.

I have not followed this bug for the last 6 months and meanwhile @justus and @neal moved on to the pEp company and are not any longer available to work on this. Although, I made the last pinentry release I do no closely follow the development. What I noticed is that we still don't have an EFL based pinentry despite that I explained them several times that I would like to see EFL in pinentry proper. I can't remember what the Mike Blumenkrantz version is or that there have been two pending versions at all. The thread is pretty long and I have note read it in its full length.

Proceeding with a fork, and likely will remove other interfaces and just maintain another version of pinentry for EFL. Maybe renamed to pinentry-efl, and only have that and tty and curses interfaces in addition to EFL.

In T3739#109615, @aheinecke wrote:

The default Pinentry for Windows is pinentry-qt it should both be accessible with descriptions and screenreader API support and it should allow you to paste in passphrases. The passphrase length is limited at 255 characters.

BTW, using a long passphrase for public key encryption is in almost all cases useless. The passphrase is there to protect the private key, the passphrase is never sent to another site and will only be seen by gpg-agent, pinentry and the tty I/O software of the OS.

FWIW, Running gpg from the commandline with option -v shows the pinentry flavor.

The default Pinentry for Windows is pinentry-qt it should both be accessible with descriptions and screenreader API support and it should allow you to paste in passphrases. The passphrase length is limited at 255 characters. This limitation comes from GnuPG and is there both for Windows and Linux. Have you tested Pinentry-qt with a screenreader?

Moving on, I will just look to make a stand along project for efl-pinentry interface. I withdraw my previous submission. Welcome to resume and move forward with Mike Blumenkrantz version. Thanks!

Not sure this should remain open. Months later a release was done excluding this. Originally mentioned on list in October 2016. Over a year later still not included. Very discouraging. I guess I can just see about having this external for myself. Shocking that FLTK and QTK see more usage than EFL which is part of Tizen OS. Clearly issues with either me, or EFL. Some reason it was excluded and being ignored. Seems nothing I can do either way. Oh well, I did all I could for months. On a very small contribution...

I could have sworn a patch/pr was merged into repo or something. It seems it was not. Guess I must be mistaking it for some other contribution. Guess I will give up on trying to get EFL into next pinentry release. Which may take another year or so. Despite the fact I have been using it daily for many months now. Oh well.

Why without it was already committed to repo? Is there some problem I
am not aware of?

Released. Unfortunately without EFL but we need to have a release after more than a year.

So why isn't app->setWindowIcon(QIcon(QLatin1String(":/document-encrypt.png"))); a desktop environment thing?

This is a distribution or desktop environment thing. We maintain only the upstream version.

The --grab/--nograb to my knowledge has nothing to do with the handling of the DISPLAY variable. Which is not used by Wayland. I believe Wayland uses WAYLAND_DISPLAY. @4tmuelle you may want to open a new task on the DISPLAY variable handling.

In T3279#101923, @werner wrote:

I have changed gpg-agent to make --no-grab the default. The new option --grab can be used to revert this.

Good idea.

Thanks.

Any update on this? Ready to do a pinentry release?

OK, thanks for the info.

Sorry for the delayed response. I am in fact on pinentry 1.0.0, and haven't tested master yet. Looking forward to the patch!

Avoid moving the window ourselves if the cursor happens to be on the same monitor than the currently focused window, since in that case the window will already be on the right monitor.

I am not sure I agree with the “cryptic error message” bit. I would think anyone knowledgeable enough to play with LC_ALL (or any other LC_* variable) should understand what “a locale function failed” means and conclude that maybe the best way to fix the problem is to leave LC_ALL alone.

Is this even something that we can control?

I just realized that my fix for T3253 was incomplete, it only works if grabbing is enabled. With GnuPG Agent not requesting grabbing by default since 2.1.23, that would make the fix useless in the default configuration. Coming with a new patch soon...

In T3279#101995, @gouttegd wrote:

Password quality evaluation is actually performed by the GnuPG Agent, not by the pinentry programs

Me personally I see T2103 as more pressing blocker to next release

Thanks for that. gpg-agent 2.1.23 or 2.2.0 will have a new default of --no-grab which can be reverted using the new --grab.

I have changed gpg-agent to make --no-grab the default. The new option --grab can be used to revert this.

In T3279#101865, @werner wrote:

Grabbing the keyboard is an important X feature and not related to gtk etc.

Grabbing the keyboard is an important X feature and not related to gtk etc.
It has two purposes:

• Make sure that the Pinentry has the focus
• Avoid that other users can grab the keyboard and snoop on the input.

These days the latter is not so important anymore, given that most of us have only a single user on the systems.

Hilarious! Not sure if its best to re-comment or edit. Seems phab has edit ability so I tend to do that... I need to slow down and re-read before setting sail :)

@wltjr Great :)

Just corrected :)

@wltjr Thanks for your comments. I think you mistyped the second bug number, T2013 seems unrelated to what you say.

I think a decision should be made about grabbing. Since the gtk pinentry interface seems to be the only one that does grabbing. I need to confirm again, but last I checked, as commented on list, Wayland lacks any grabbing specification or ability. Making this a X only feature of GTK. It seems the patches 1 2 for this are for xwayland, not regular wayland stuff. Which seems to be why bugs like this one on RedHat are open.

I think disabling the tooltips for the gtk Pinentry is the way to go.