Well, I don't think we'll add platform-specific X11 code to pinentry-qt just to check for an invalid DISPLAY. We are using Qt so that we don't have to deal with platform-specific stuff. I have no intention to look into this and, given Wayland, investing any more time in X11 feels wasted. We might accept a patch that can be used by all GUI pinentries to check for a usable DISPLAY.

"ikloecker (Ingo Klöcker)" wrote:

ikloecker added a comment.

How is "invalid DISPLAY" defined? `DISPLAY=invalid`? Anything that's not `DISPLAY=:<some number>`? Why do screen and tmux have to use an extra-wurst?

[...]

Apparently, DISPLAY is hostname:displaynumber.screennumber where hostname and .screennumber are optional and where hostname is a hostname or maybe host/unix. Does hostname include IPv6 address literals? Anyway, I guess the only sensible heuristic is to consider any DISPLAY value that contains : as valid.

How is "invalid DISPLAY" defined? DISPLAY=invalid? Anything that's not DISPLAY=:<some number>? Why do screen and tmux have to use an extra-wurst?

In T8156#216401, @ikloecker wrote:

I'm not sure if we should consider env DISPLAY=invalid pinentry-qt a valid test.

[...]

So, I guess, @ametzler1's suggestion to remove the check for isX11SessionType is the correct solution. DISPLAY=invalid would still not work, but I think that's acceptable.

As noted by @ametzler1 pinentry-qt has such a fallback. Of course, we can try to improve the heuristics pinentry-qt uses.

We talked about this in our developer meeting on Monday. I have never experienced the problem because I use the Qt version only on Windows and for my own use I use the Gtk version. In any case I think that Qt and fltk should fallback to curses to cover the case of using the Pinentry for a system startup on the console (e.g. the g13 case) with later switching to a GUI. And of course for those users who switch between GUI and console.

Just a quick note: I wouldn't remove the gtk-2 pinentry unless you have made sure that all still supported long-term enterprise distributions (RHEL, SLES, Debian, ...) support something newer. I have kept the Qt 4 pinentry although Qt 4 is obsolete since ages because some people still used it.

Pushed the change of gpgme: rM8b89678aed6d: Fix passphrase cancel handling.

It seems that pinentry-curses defaults to "OK".
(my branch for GTK-4, same.)

Cancel (in pinentry-qt) was made default with rP291089ed476d75c71ef1984a7c081d27e357437d. Marc's ChangeLog entry was

• qt4/main.cpp: (qt_cmd_handler) make Cancel the default button for CONFIRM

I consider again about Ben's change. It could be simply support of the detection of the cancel situation where gpgme should return GPG_ERR_CANCELED (not related to single cancellation vs. whole cancellation).

I can't remember why Ben introduced the new status. OTOH, I wish that the Qt-Pinentry also emits a button_info line for closing the window. Normal users don't notice the difference but if you have a lot of private keys and you get a mail which has only hidden recipients the full_canceled is pretty useful. Also for other tasks like allow-mark-trusted: On Windows with the qt-pinentry I am always cursing about this but on my box I only need to close the pinentry window to get a fully_canceled

Afaict neither QT nor FLTK offer an equivalent to gtk-2's gtk_init_check() so there is no trivial change to get the same functionality.

I think "O" is a better key:

We need to change the accelerator. Right now gpg-agent uses

Taking over revision to close it as done.

Fixed in 1.3.2.

Interesting. That means to replace hundreds of scripts in an average organization :-(.

@ametzler1 Thank you.

Some data points:
The latest version of the standard (issue 8) has "The -a and -o binary primaries and the '(' and ')' operators have been removed." instead of "obsoleted" https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.html

test -a is not a POSIX construct, I intentionally avoided it.

Thanks for fixing this.

@ametzler1 Thank you for your report.
I modified a bit (not using && between two test but using -a for a single test command), and pushed the change:
rP121494245f49: build: Allow build with fltk 1.4.

In the meantime pinentry has been updated also for VSD 3.4.

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10

nr.1
nr.2
schwarz
weiß

works in vsd3.3.3, tested with VS-Desktop-3.3.90.8-Beta

The gold rule of tab order is that tab order follows the usual reading direction, i.e. line by line from left to right. If you press Enter after entering the password in the first input field then the focus should jump to the second input field.

Looks good to me on gpg4win-5.0.0-beta357 @ win10:

The fix should be available in gpg4win-5.0.0-beta350.

Noteworthy changes in version 1.3.2 (2025-07-28)

not sure if this really is an issue, maybe for a person proficient with a a screenreader the behavior ist ok, after the fix of the show/hide button is done?

This has been fixed in pinentry-qt5 (which is used by VSD 3.x).

In T6883#199155, @ebo wrote:

I guess this is done if QT6 versions have a pinentry?

I guess this is done if QT6 versions have a pinentry?

This was using GCC to build, but on AIX. I believe support for dollar signs in identifiers are platform specific.

GCC allows dollars in identifier, that's the reason why we haven't encountered this issue, I suppose.

Thank you for your report.

The formatted display of the symmetric passphrase is configurable: gpg-agent.conf option pinentry-formatted-passphrase

Here we go:

Alright, my above putenv option won't work because it modifies the session environment and thus needs to be run for each gpg-agent session (connection). Adding a putenv_startrup option would help here but this way each connection could chnage the environment - also not good. In the end a way to modify the used environment variables, as you suggested, is a better way.

Yes, the workaround is to use a pinentry wrapper script that sets the value back to the correct one and then invokes the real pinentry.

Werner says this won't be fixed…
Because the system can be configured to use constraints which we can't explain except in ABNF, which won't help users.

Maybe the title should be "Password - Kleopatra" (or similar) if the operation was triggered by Kleopatra.

as far as I understand both the Gtk and Qt implementation are using pinentry_get_title which does the /proc stuff, but this is only on Linux. On Windows, pinentry_get_title will return the value set in pinentry_init, in our case pineentry-qt or pineentry-qt5.