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