From xemacs-m  Wed Aug 27 22:56:24 1997
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id WAA06292;
	Wed, 27 Aug 1997 22:56:23 -0500 (CDT)
Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs)
	id VAA29392; Wed, 27 Aug 1997 21:51:28 -0600 (MDT)
Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id VAA09675; Wed, 27 Aug 1997 21:51:23 -0600
Date: Wed, 27 Aug 1997 21:51:23 -0600
Message-Id: <199708280351.VAA09675@fast.cs.utah.edu>
X-Mailer: VM 5.96 (beta)/19.15 XEmacs Lucid
From: Bart Robinson <lomew@cs.utah.edu>
To: SL Baur <steve@xemacs.org>
Cc: <jari.aalto@poboxes.com> (pgp preferred ssjaaa@uta.fi | pgp -fka),
        xemacs-beta@xemacs.org
Subject: Re: PGP security threat alert
In-Reply-To: <m2vi0w4dpf.fsf@altair.xemacs.org>
References: <199708232201.SAA22000@helene.tele.nokia.fi>
	<199708232210.PAA12803@xemacs.eng.sun.com>
	<m2vi0w4dpf.fsf@altair.xemacs.org>

On 1997-8-23 SL Baur <steve@xemacs.org> wrote:
 > Martin Buchholz <mrb@Eng.Sun.COM> writes:
 > > Instead we should have a way to suppress recording of keystrokes during
 > > execution of a lisp function, which could be used by passwd.el.
 > 
 > That sounds more useful.  It doesn't sound any more secure, but it's a 
 > more correct thing to do.

I have a patch for this below.  It allows constructs like

	(let ((record-keystrokes nil) pw)
	  (setq pw (read-passwd "Password: "))
	  ...)

 > Implementing bad security is much worse than implementing no security
 > at all.  

I agree that if a bad guy (or girl) has access to your session
then clearing/inhibiting your recent-keys isn't going to save
the day.  But I believe keeping your password out of recent-keys
is good hygiene, trivial to implement, and can even prevent the
unlikely situation where someone is sitting with you helping out
and you accidently hit C-h l and show them something private.

 >	    If you're trying to protect against someone with physical access 
 > to a running emacsen where you have just typed in a (PGP) password,
 > you'll also have to make sure the text is wiped out of other places in 
 > the lisp runtime lest forcing a coredump reveal all.  I'm not sure
 > that's worth it as it will require a substantial amount of work to do
 > right and the best solution is to not leave your session unattended.

I'm not an expert on elisp internals, but if one follows the
recommendations in passwd.el (zeroing the returned password)
then I believe this is a non-issue.  I did a read-passwd then
zeroed the result and then made my xemacs dump core and didn't
find the password anywhere.

-- bart

- - - - - - - - - - - - - - - - tear off - - - - - - - - - - - - - - - -

*** event-stream.c	1997-08-23 14:35:41-06	1.1
--- event-stream.c	1997-08-27 13:56:45-06
*************** command_builder_find_leaf (struct comman
*** 3192,3197 ****
--- 3192,3200 ----
  Lisp_Object recent_keys_ring;
  int recent_keys_ring_index;
  
+ /* Boolean specifying whether keystrokes should be added to recent-keys. */
+ static int record_keystrokes;
+ 
  DEFUN ("recent-keys", Frecent_keys, 0, 0, 0, /*
  Return vector of last 100 or so keyboard or mouse button events read.
  This copies the event objects into a new vector; it is safe to keep and
*************** push_recent_keys (Lisp_Object event)
*** 3336,3341 ****
--- 3339,3347 ----
    Lisp_Object e
      = vector_data (XVECTOR (recent_keys_ring)) [recent_keys_ring_index];
  
+   if (! record_keystrokes)
+     return;
+ 
    if (NILP (e))
      {
        e = Fmake_event ();
*************** vars_of_event_stream (void)
*** 4201,4206 ****
--- 4207,4219 ----
    staticpro (&last_point_position_buffer);
  
    recursive_sit_for = Qnil;
+ 
+   DEFVAR_BOOL ("record-keystrokes", &record_keystrokes /*
+ *Variable to control whether keystrokes are logged.
+ When this is t, keystrokes are recorded and available through
+ `recent-keys' or `view-lossage'.
+ */ );
+   record_keystrokes = 1;
  
    DEFVAR_INT ("echo-keystrokes", &echo_keystrokes /*
  *Nonzero means echo unfinished commands after this many seconds of pause.

