Page MenuHome GnuPG

pinentry-qt should fallback to curses if $DISPLAY is set but unavailable
Open, LowPublic

Description

https://bugs.debian.org/635935 reports that pinentry-gtk-2 (and presumably other
graphical pinentries) fail hard if $DISPLAY is set but cannot be opened.

They fall back to curses if $DISPLAY is unset. Maybe they should fallback to
curses if they know they are connected to a TTY *and* $DISPLAY is set but
unreachable?

Below is an example that could have succeeded if this workaround was in place:

0 dkg@alice:~$ DISPLAY=:noexist pinentry-gtk-2

(pinentry-gtk-2:16257): Gtk-WARNING **: cannot open display: :noexist
1 dkg@alice:~$

Event Timeline

neal claimed this task.

Hm, this is indeed fixed for pinentry-gtk2 and pinentry-gnome3, but pinentry-qt
is still broken:

0 $ DISPLAY=:3 pinentry-qt
QXcbConnection: Could not connect to display :3
Aborted
134 $

anyone skilled in qt want to fix this outstanding issue?

werner added a subscriber: aheinecke.
werner added a subscriber: werner.

Andre, can you look at it?

Testing this I noticed that the curses fallback did not work at all for Qt5
versions of pinentry-qt even if display was unset. This i fixed with cd7b35e

But the DISPLAY=:noexist case is more complicated. The GTK pinentry does a
gtk_init_check which Qt does not have. I don't want to mess with X directly and
would have to look into this more how to do this then only when X is used etc.

There is a similar question on stackoverflow and I don't find any answers there
acceptable:
http://stackoverflow.com/questions/28525435/qt-equivalent-to-gtk-init-check

I've changed the topic to reflect that this is a feature currently not available
in pinentry-qt but I don't see it as a high priority issue.

aheinecke renamed this task from graphical pinentries might try to fallback to curses if $DISPLAY is set but unavailable to pinentry-qt should fallback to curses if $DISPLAY is set but unavailable.Feb 13 2017, 6:01 PM
aheinecke lowered the priority of this task from Normal to Low.Apr 24 2017, 5:55 PM