From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Helm Newsgroups: gmane.emacs.help Subject: Re: isolating history with buffer-local variables Date: Wed, 20 May 2015 15:52:42 +0000 Message-ID: <4F35C3B0-4EA7-4B66-8006-F5048B1BF8B4@tenpoint.co.nz> References: <54AE8A33-FB8D-4F63-8BC1-F84DB290EF05@tenpoint.co.nz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1432137067 7630 80.91.229.3 (20 May 2015 15:51:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 May 2015 15:51:07 +0000 (UTC) To: "help-gnu-emacs@gnu.org" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed May 20 17:51:00 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yv6Gm-0003oq-Pe for geh-help-gnu-emacs@m.gmane.org; Wed, 20 May 2015 17:50:57 +0200 Original-Received: from localhost ([::1]:52907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv6Gm-00047D-4H for geh-help-gnu-emacs@m.gmane.org; Wed, 20 May 2015 11:50:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv6GG-00041i-Nm for help-gnu-emacs@gnu.org; Wed, 20 May 2015 11:50:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yv6GD-0000Xi-G1 for help-gnu-emacs@gnu.org; Wed, 20 May 2015 11:50:24 -0400 Original-Received: from mail.cloudless.co.nz ([202.20.2.65]:11270 helo=CL-DAG01.cloudless.local) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv6GC-0000Wh-Vt for help-gnu-emacs@gnu.org; Wed, 20 May 2015 11:50:21 -0400 Original-Received: from CL-DAG01.cloudless.local (10.100.10.20) by CL-DAG01.cloudless.local (10.100.10.20) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 21 May 2015 03:53:11 +1200 Original-Received: from CL-DAG01.cloudless.local ([fe80::c8af:a0f:50d9:c20]) by CL-DAG01.cloudless.local ([fe80::c8af:a0f:50d9:c20%13]) with mapi id 15.00.0775.031; Thu, 21 May 2015 03:52:42 +1200 Thread-Topic: isolating history with buffer-local variables Thread-Index: AQHQkxUBGNjS4Iqe70+y+k2lJpIvRA== In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.57.35.49] Content-ID: X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 202.20.2.65 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:104499 Archived-At: > On 16/05/2015, at 11:32 am, Stefan Monnier wro= te: >=20 >> I think there are other use-cases though. For instance, I use Emacs to >> edit confidential files that I don't want leaking into incremental >> backups or off-site syncing of ~/.emacs.d/ (all the usual financial, >> medical, legal stuff). >=20 > Could you give details of those use-cases, to see how much of it is very > specific to your particular setup, and how much of it could apply to > a wider audience? >=20 > I'm specifically wondering why copying "foo" to "foo~" or to "#foo#" > would be a problem (assuming "foo" itself is modified) w.r.t > incremental backups or off-site syncing. Or are your worries more > specifically about leaking data from those files via history variables > saved in ~/.emacs.d ? > [ Another way to attack this problem is to try and avoid > syncing/backing-up the saved-history data in ~/.emacs.d. > Maybe this history data should never be saved to ~/.emacs.d but to > another place instead? ] My primary concern is losing control of copies or fragments of confidential= files.=20 If I edit a confidential file foo.txt, which is stored in plain text on my = file-server, Emacs potentially creates at least three additional copies or = fragments of foo.txt created on the local machine - foo.txt~x~, #foo.txt# a= nd .emacs-history.=20 My file-server does encrypted backups to keep the originals secure, but I a= lso I do hourly incremental rsync backups of $HOME on each client machine, = so another three copies and fragments of foo.txt find their way to that mac= hine as well. These backups are rotated off-site. I also sync ~/.emacs.d to Dropbox for continuity and so I can access my Ema= cs setup, backups, auto-saves and histories from any machine, but that mean= s another three copies and fragments of foo.txt now exist up on Dropbox. So, all up, for a single edit, I could end up with nine or more uncontrolle= d copies or fragments of foo.txt floating around. For normal files, this is= a good thing, but not for private data (to my mind at least). Where the ed= it takes place on a shared machine or a portable device, there is also an a= dditional risk of theft. Similarly, if I use Tramp to remote into a client's machine and edit foo.co= nf for admin purposes, Emacs creates foo.conf~x~ #foo.conf# and saves file = fragments in .emacs-history on the local machine. The remote sysadmin can a= dd file variables: ;; backup-inhibited: t ;; eval: (auto-save-mode 0) to foo.conf to prevent the copies being created, but has no simple control = over saved rings and histories. Out of interest, I ran a series of little tests to see what Emacs saves in = different situations. This table shows the data that was committed to the l= ocal disk when editing plain text and encrypted files (via EPA) in differen= t locations.=20 +-------------------------------+ |File content | +---------------+---------------+ |plain-text |encrypted | +---------+---------+---------------+---------------+ |File |Local FS |Fp Ap Bp Hp Rp |Fe - Be Hp Rp | |loc +---------+---------------+---------------+ | |LAN |Fp Ap Bp Hp Rp |Fe - Be Hp Rp | | +---------+---------------+---------------+ | |Remote |Fp Ap Bp Hp Rp |Fe Ap Be Hp Rp | +---------+---------+---------------+---------------+ Where: F =3D visited file (on user save) A =3D auto-saves (to ~/.emacs.d/auto-saves) B =3D backups (to ~/.emacs.d/backups) H =3D minibuffer history (et al) (to ~/.emacs.d/.emacs_history via savehist= ) R =3D kill-ring (et al) (also to ~/.emacs.d/.emacs_history via savehist) And: p =3D data was saved to disk in plain text e =3D data was saved to disk encrypted The results are largely as expected, with the exception of the handling of = auto-saves on remote machines (the remote encrypted gpg was saved in plain = text on the local machine). Perhaps this is a bug. That issue aside, I hope private-mode will enable something like the follow= ing. That is, make it easier to control what private data is committed to d= isk without an explicit user save. +-----------------------------------------------------------= ----+ |File content = | +---------------+-------------------------------+-----------= ----+=20 | PRIVATE | =20 +---------------+---------------+---------------+-----------= ----+ |plain-text |plain-text |encrypted |encrypted = | +----+---------+---------------+---------------+---------------+-----------= ----+ |File|Local FS |Fp Ap Bp Hp Rp |Fp - - - - |Fe - - - - |Fe - Be Hp= Rp | |loc +---------+---------------+---------------+---------------+-----------= ----+ | |LAN |Fp Ap Bp Hp Rp |Fp - - - - |Fe - - - - |Fe - Be Hp= Rp | | +---------+---------------+---------------+---------------+-----------= ----+ | |Remote |Fp Ap Bp Hp Rp |Fp - - - - |Fe - - - - |Fe - Be Hp= Rp | +----+---------+---------------+---------------+---------------+-----------= ----+ Nick