[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: isolating history with buffer-local variables
From: |
Nick Helm |
Subject: |
Re: isolating history with buffer-local variables |
Date: |
Wed, 20 May 2015 15:52:42 +0000 |
> On 16/05/2015, at 11:32 am, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> 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).
>
> 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?
>
> 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.
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# and
.emacs-history.
My file-server does encrypted backups to keep the originals secure, but I also
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 machine as
well. These backups are rotated off-site.
I also sync ~/.emacs.d to Dropbox for continuity and so I can access my Emacs
setup, backups, auto-saves and histories from any machine, but that means
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 uncontrolled
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 edit
takes place on a shared machine or a portable device, there is also an
additional risk of theft.
Similarly, if I use Tramp to remote into a client's machine and edit foo.conf
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 add
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 local
disk when editing plain text and encrypted files (via EPA) in different
locations.
+-------------------------------+
|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 = visited file (on user save)
A = auto-saves (to ~/.emacs.d/auto-saves)
B = backups (to ~/.emacs.d/backups)
H = minibuffer history (et al) (to ~/.emacs.d/.emacs_history via savehist)
R = kill-ring (et al) (also to ~/.emacs.d/.emacs_history via savehist)
And:
p = data was saved to disk in plain text
e = 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 following.
That is, make it easier to control what private data is committed to disk
without an explicit user save.
+---------------------------------------------------------------+
|File content |
+---------------+-------------------------------+---------------+
| PRIVATE |
+---------------+---------------+---------------+---------------+
|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
- isolating history with buffer-local variables, Nick Helm, 2015/05/12
- Re: isolating history with buffer-local variables, Stefan Monnier, 2015/05/13
- Re: isolating history with buffer-local variables, Nick Helm, 2015/05/14
- Re: isolating history with buffer-local variables, Stefan Monnier, 2015/05/15
- Re: isolating history with buffer-local variables,
Nick Helm <=
- Re: isolating history with buffer-local variables, Stefan Monnier, 2015/05/20
- Re: isolating history with buffer-local variables, Stefan Monnier, 2015/05/24
- Re: isolating history with buffer-local variables, Nick Helm, 2015/05/24
- Message not available
- Re: isolating history with buffer-local variables, Pascal J. Bourguignon, 2015/05/24
- Re: isolating history with buffer-local variables, Nick Helm, 2015/05/24