pinentry: Front ends
1
1 2 Front Ends
1 ************
1
1 There are several different flavors of PINENTRY. Concretely, there are
1 Gtk+2, Qt 4, Gnome 3, Emacs, curses and tty variants. These different
1 implementations provide higher levels of integration with a specific
1 environment. For instance, the Gnome 3 PINENTRY uses Gnome 3 widgets to
1 display the prompts. For Gnome 3 users, this higher level of
1 integration provides a more consistent aesthetic. However, this comes
1 at a cost. Because this PINENTRY uses so many components, there is a
1 larger chance of a failure. In particular, there is a larger chance
1 that the passphrase is saved in memory and that memory is exposed to an
1 attacker (consider the OpenSSL Heartbeat vulnerability).
1
1 To understand how many components touch the passphrase, consider
1 again the Gnome 3 implementation. When a user presses a button on the
1 keyboard, the key is passed from the kernel to the X server to the
1 toolkit (Gtk+) and to the actual text entry widget. Along the way, the
1 key is saved in memory and processed. In fact, the key presses are
1 probably read using standard C library functions, which buffer the
1 input. None of this code is careful to make sure the contents of the
1 memory are not leaked by keeping the data in unpagable memory and wiping
1 it when the buffer is freed. However, even if they did, there is still
1 the problem that when a computer hibernates, the system writes unpagable
1 memory to disk anyway. Further, many installations are virtualized
1 (e.g., running on Xen) and have little control over their actual
1 environment.
1
1 The curses variant uses a significant smaller software stack and the
1 tty variant uses an even smaller one. However, if they are run in an
1 X terminal, then a similar number of components are handling the
1 passphrase as in the Gnome 3 case! Thus, to be most secure, you need to
1 direct GPG Agent to use a fixed virtual console. Since you need to
1 remain logged in for GPG Agent to use that console, you should run there
1 and have 'screen' or 'tmux' lock the tty.
1
1 The Emacs pinentry implementation interacts with a running Emacs
1 session and directs the Emacs instance to display the passphrase prompt.
1 Since this doesn't work very well if there is no Emacs running, the
1 generic PINENTRY backend checks if a PINENTRY-enabled Emacs should be
1 used. Specifically, it looks to see if the 'INSIDE_EMACS' variable is
1 set and then attempts to establish a connection to the specified
1 address. If this is the case, then instead of, e.g., 'pinentry-gtk2'
1 displaying a Gtk+2 pinentry, it interacts with the Emacs session. This
1 functionality can be explicitly disabled by passing
1 '--disable-inside-emacs' to 'configure' when building PINENTRY.
1
1 Having Emacs get the passphrase is convenient, however, it is a
1 significant security risk. Emacs is a huge program, which doesn't
1 provide any process isolation to speak of. As such, having it handle
1 the passphrase adds a huge chunk of code to the user's trusted computing
1 base. Because of this concern, Emacs doesn't enable this by default,
1 unless the 'allow-emacs-pinentry' option is explicitly set in his or her
1 '.gnupg/gpg-agent.conf' file.
1
1 Similar to the inside-emacs check, the PINENTRY frontends check
1 whether the 'DISPLAY' variable is set and a working X server is
1 available. If this is not the case, then they fallback to the curses
1 front end. This can also be disabled by passing
1 '--disable-fallback-curses' to 'configure' at build time.
1