[git] Pinentry - branch, master, updated. pinentry-0.9.5-10-g43f975b

by Neal H. Walfield cvs at cvs.gnupg.org
Tue Jul 28 13:48:50 CEST 2015


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The standard pinentry collection".

The branch, master has been updated
       via  43f975bf0348663dc8b01737dee5b15244ef7ee8 (commit)
      from  a4694dcda0fe27852be20db3017f9313adf361a3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 43f975bf0348663dc8b01737dee5b15244ef7ee8
Author: Neal H. Walfield <neal at gnu.org>
Date:   Tue Jul 28 11:53:25 2015 +0200

    doc: Describe the frontends and their security implications.
    
    * doc/pinentry.texi: Describe the frontends and their security
    implications.
    
    GnuPG-bug-id: 2034

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

-----------------------------------------------------------------------

Summary of changes:
 doc/pinentry.texi | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)


hooks/post-receive
-- 
The standard pinentry collection
http://git.gnupg.org




More information about the Gnupg-commits mailing list