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.

Well, I am using pinentry-gtk2 1.0.0 on Awesome, and I just performed some tests with master as well.

I'm not sure if this post ever made it into a bug report, but has master been tested with tiling WM like awesome to see if issue is fixed? https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032608.html (if not I'm sure robbat2 is helpful enough with that if picking up the thread)

@justus Are the FLTK and the EFL ready for a release (which we could mark as beta test versions)

Well, the backlog is here: pinentry

Users expect to be able to make signatures (or to fail to make signatures) reliably and understandably. the fact that some pinentries fail in some obscure combinations of circumstances makes the process of making signatures unreliable and incomprehensible.

What behavior do you expect in this case?

The Debian report includes multiple workarounds for the quite unusual setup. So, I am closing here.

And SETQUALITYBAR.

Is this even something that we can control? This stuff is usually up to the window manager, and although some accept hints, this is not really well defined. For example, gcry_prompt_set_caller_window accepts a window-id-string and says:

It is unclear what the benefit of such a console pinentry for windows would be.

Loopback is now officially supported, so I am closing this.

This seems to depend on the window manager. With Fedora 26 and Gnome 3 desktop, a full grab is not allowed anymore, and there is no close button on the modal dialog. With i3 and pinentry-gtk-2, the grab is strong but there also are no close buttons.

I tested this with Fedora 26 and the Gnome 3 desktop. and could not reproduce this. So maybe it got fixed upstream.

I just tested this with Fedora 26, pinentry-gnome3 0.9.7 and Gnome Keyring 3.20.1. See below for a full trace. If this doesn't work for you, check that you have compiled pinentry with libsecret, and did not deactivate the feature in the gpg-agent.conf.

pinentry-curses on the same terminal as the application was never intended to be automagical - from the start it was clear that during any operation that may trigger a pinentry dialog, the application would have to stop reading from the terminal, and it would have to redraw the screen when gnupg finishes. That's just a limitation of the terminal that can not be overcome (there is no focus grab, no save/restore of the terminal state, etc). This needs to be raised with the emacs developers.

Except for some tangential lingering questions, all issues in this report are attended to, and all subtasks are resolved.

Done in e57bcb7a2acff3a61a342d24e6a55407bf736631

This was resolved upstream by using no-grab (and otherwise would rather seem to be a bug in Gnome 3 classic mode anyway).

That issue is best taken up with the enigmail maintainers. If you report it there, feel free to add a link here. Thanks!

I can't reproduce this in Fedora 26. If this is still an issue, please reopen and provide more information. I tested pinentry-gnome3, pinentry-gtk-2 and pinentry-qt.

Fixed in 6053cb4f. The third patch was obsolete due to use of FIND_QT macro.

Done.