Well, the backlog is here: pinentry

Of these, T2145 seems relevant because you adjusted the window title, maybe you can add the keyid as well.

The others are minor problems or feature requests.

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

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)

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

I can confirm that the tooltip on the show/hide button does create problems with grabbing.

With the tooltip enabled, pinentry-gtk-2 always needs between 1000 to 3000 tries to grab the keyboard. Pinentry-gtk-2 still works on my system because that's less than the 4096 max_tries limits.

Without the tooltip, as reported by robbat2, the keyboard is grabbed immediately, no retry is ever needed.

Why would a tooltip interfere with keyboard grabbing is beyond me, but since it does, I tend to agree with robbat2's suggestion to drop the tooltip until the issue is fixed in Gtk.

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 asked about this for EFL pinentry on list 1 2. I left out the grabbing ability due to it being a X only feature at this time. Not to mention personal dislike, but that is a configurable option. I was more interested in why only the GTK interface to pinentry grabbed and not others. Though I was informed I think the KDE one does, and maybe Gnome. I wanted to be consistent, and not sure if it was required or not. Seemed to not be per discussion on T2905.

Me personally I see T2103 as more pressing blocker to next release, as that seems totally bogus and broken across the board. But I would not make that a "show stopper" issue.

Given that Wayland does not have grabbing, I think this should be dropped from all until that is the case, if that is the case. Otherwise this will all be guaranteed to break in the future. If not now for anyone using Wayland.

Either way not sure if the GTK grabbing issue with show/hide tooltip is something to hold back a release, but that is up to GnuPG/Pinentry.

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

Just corrected :)

@wltjr Great :)

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 :)

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.

Thus my suggestion is to make gpg-agent's --no-grab the default and a --grab option so that users can revert to the current behaviour of the Pinentries. @gouttegd would you mind to change the patch related to the tooltips so that tooltips are only disabled in --grab mode?

In T3279#101865, @werner wrote:

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

This is hotly debated wrt to Wayland. For "security" reasons Wayland protocol does not allow for such. That may change, but at this time it seems Wayland devs have resisted and stood their ground. I am not sure how practical that will be for many applications. I take no position either way.

I myself rely on many features of X not in Wayland. The future is Wayland, and it is best IMHO to make apps portable now rather than later. Not to mention behaving one way under X and another way under Wayland. I am not super excited about Wayland due to all these changes. That break existing applications. Then the time before Wayland will be feature compatible with X. Not to mention bugs along the way. Though seems some features will get dropped, and grabbing maybe one permanently.

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

@wltjr

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

Password quality evaluation is actually performed by the GnuPG Agent, not by the pinentry programs (which merely display the quality value sent by the agent). If the evaluation code needs improvement (and for the record, I agree that it does), that's to be done in the agent. So T2103 is not really a blocker for pinentry itself.

In T3279#101995, @gouttegd wrote:

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

Ok so block next release of GnuPG or the agent :) No worries either way. Not sure that password quality aspect is used much in pinentry.

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

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.

Does this relate to gpg communicating the DISPLAY variable (how does that even work under Wayland?)?
It's a mild nuisance for running gpg in a (bubblewrap) container, e.g. Flatpak, because you'd have to guess the host's DISPLAY variable which is a bit weird. But less so than having to tell the host to configure the agent with keep-display.

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.

The --grab/--nograb just passes a conditional to code internally so applications can ensure nothing else can capture keyboard/mouse input while pinentry dialog is present. You can see the usage in like the GTK interface.

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

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.