Recent undo-tree package leaves *.~undo-tree~ files

[Antiarchitect]

Description

After undo-tree upgrade spacemacs starts leaving *.~undo-tree~ files on fs

Reproduction guide 🪲

• Start Emacs
• Edit some file
• git status

Observed behaviour: 👀 💔
See *.~undo-tree~ files related to those I edit

Expected behaviour: ❤️ 😄
No extra files are created

System Info 💻

• OS: gnu/linux
• Emacs: 28.0.91
• Spacemacs: 0.999.0
• Spacemacs branch: develop (rev. 18ad975)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(auto-completion ansible docker emacs-lisp erlang git
                 (go :variables go-backend 'lsp)
                 (helm :variables helm-no-header t)
                 html javascript
                 (json :variables json-fmt-tool 'prettier)
                 (lsp :variables lsp-rust-server 'rust-analyzer)
                 multiple-cursors nginx org php puppet python ruby
                 (rust :variables rust-backend 'lsp)
                 (shell :variables shell-default-height 100 shell-default-position 'top shell-default-term-shell "~/Sync/dotfiles/sway-alacritty.sh")
                 shell-scripts sql
                 (syntax-checking :variables syntax-checking-enable-tooltips nil)
                 systemd themes-megapack
                 (treemacs :variables treemacs-show-hidden-files t treemacs-sorting 'alphabetic-asc treemacs-use-filewatch-mode t treemacs-use-follow-mode t)
                 typescript
                 (yaml :variables yaml-enable-lsp nil))

• System configuration features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM XWIDGETS GTK3 ZLIB

Backtrace 🐾

[arifer612]

This is because of a change in the default value of one of the custom variables upstream. The relevant diff is shown in the source block below. You can view the whole diff here

@@ -939,7 +941,7 @@ within the current region."
   :type 'boolean)
 
 
-(defcustom undo-tree-auto-save-history nil
+(defcustom undo-tree-auto-save-history t
   "When non-nil, `undo-tree-mode' will save undo history to file
 when a buffer is saved to file.

This is a very easy fix, all you need to do is to set that variable back to nil. I am not in favour of changing this in the spacemacs-editing layer since this feature helps safeguard any unfortunate accidents and can easily be fixed with a small configuration line anyways.

(with-eval-after-load 'undo-tree
  (setq undo-tree-auto-save-history nil))

[lebensterben]

@arifer612

Thanks for the investigation.
I'm thinking about moving the auto-generated ~undo-tree~ files into ~/.emacs.d/.cache. (But I haven't checked about whether this is doable.)

[arifer612]

That seems totally possible. All we need to do is to configure this function:

(defun undo-tree-save-history-from-hook ()
  (when (and undo-tree-mode undo-tree-auto-save-history
	     (not (eq buffer-undo-list t))
	     buffer-file-name
	     (file-writable-p
	      (undo-tree-make-history-save-file-name buffer-file-name)))
    (undo-tree-save-history nil 'overwrite) nil))

and just replace the last buffer-file-name with something like (concat "~/.emacs.d/.cache" buffer-file-name). I've not tested it yet so I can't be 100% sure about it.

[arifer612]

Cross the previous comment I made. There is a simpler way to have all the backups stored in a single directory. undo-tree-history-directory-alist does exactly what you want perfectly. It places all the auto-save files of a certain regexp into a directory of your choice and if nil, it gets placed in the directory of the original file. I tried with the grab-all regexp:

(setq undo-tree-history-directory-alist '(("." . "~/.emacs.d./.cache")))

and it works perfect. It's going to need some tidying up to ensure that it is OS-agnostic but you can get the idea.

[Antiarchitect]

Guys, I'm not good with lisp frankly. Please let me know will it be fixed in the spacemacs itself or I should place something in config file :) Thank you so much in advance!

[lebensterben]

@Antiarchitect
It would be fixed in Spacemacs.

[arifer612]

@Antiarchitect
If it's bothering you too much right now and you'd rather not have any auto-save files, just add the following to your config:

(with-eval-after-load 'undo-tree
  (setq undo-tree-auto-save-history nil))

[Antiarchitect]

@lebensterben @arifer612 Thank you so much guys! ❤️

[Davidj361]

I'm also having the same issue. Wasn't sure if that was on purpose behaviour but it leaves a massive clutter imo.

[mentalisttraceur]

One relevant thought here which might tip the balance for some people is that this is another way that sensitive secrets can get leaked into the file system indefinitely and without the user realizing it.

Because on the one hand, this is a really really nice feature!

But on the other hand, most users don't expect that typing or pasting a password or private key into a text editor, then deleting or undoing it without saving it, would save that secret to disk, indefinitely, in a form that's not encrypted. (And since it's non-obviously encoded, it can add to a false sense of security once known, even though it has approximately the security of plaintext.)

[pataquets]

100% agree with @mentalisttraceur. I've completely disabled the feature due to the same secret leaking concern. I understand it's a useful feature, but I've postponed enabling it until I find the time to properly configure it in a secure way for me.

Also, due to the above mentioned reason alone, I think it should be disabled by default but easily enabled via documenting comments in the init file. The configuration instructions should also warn clearly about the security implications of doing so.
If this is not possible, at least make the default for undo-tree files the same directory that the original file, so users can easily notice the feature and decide. Everything on .cache can be provided as an example in docs, too.

In my case, I'll be configuring it later only if I manage to place the undo-tree files in the same directory as the original file but with some directory and file exceptions, eg. ~/.secrets dir (anyone doing this already?).

But dropping all of them in the .cache dir is a no-no for security, IMO.

[lebensterben]

I've not typed my password in any file even for once.

What's the scenario?

[mentalisttraceur]

@lebensterben to me your message reads very rudely - as dismissive and demanding that others do all the work of enumerating compelling-to-you possibilities while seemingly making very little effort to creatively think of even one possibility.

Also, before being dismissive, I recommend first taking stock of why you're emotionally invested in not accepting a concern as valid or likely enough. (I, personally, don't care about getting the default changed, and it's a single-variable config change to explicitly ensure our preference either way. You, apparently, care enough to willfully make little effort to think of even one possible way that something could validly happen, even though two people said it could.)

Anyway,

1. People sometimes have passwords/keys in their clipboards and

   1. hit paste while having the wrong window focused (I have this happen sometimes, luckily rarely with passwords, on systems that implement focus-follows-mouse badly - Windows last I checked was particularly bad at this since it doesn't officially support the feature, but I've also seen it recently in Emacs under GNOME+Wayland), or

   2. hit the key stroke for copy but are using one of the many imperfect keyboards out there, so one of the keys doesn't get pushed quite hard or deep enough, so the copy doesn't register, leaving the secret in the clipboard when they go to paste (for example, I have a Librem 14 laptop which came out-of-the-factory with 2-3 keys that I have to forcefully bottom-out to reliably register a keypress)

   3. are using/trying "sticky keys" and end up losing track of a modifier being latched or locked, so what was meant to be a "y" or a "v" turns into a Ctrl-y or a Ctrl-v respectively. (This isn't even the user's fault on bad/broken Sticky Keys implementations which behave in ways that do the wrong thing if you just follow muscle memory that works with correct Sticky Keys implementations - again GNOME+Wayland is an example).

2. As a heavy user of eval-last-sexp in Emacs, if I ever had reason to load a secret into a variable or function in Emacs' lisp, my first thought would be to type the expression into whichever buffer I'm in at the time and then just delete it (as opposed to first switching to a non-persisted buffer like *scratch*, or hitting M-: first).

   (Why would users sometimes have good reason to type secrets into Emacs variables or commands? Same reasons why we sometimes export secrets into environment variables or send them into a command's stdin or TTY. Many programs out there that take credentials that way, and if you're doing a one-off task you might not have a function or package on-hand which takes that credential from you with a minibuffer read and then forwards it properly to the command.)

3. When debugging frustratingly non-obviously failing login workflows (which don't always have a "show password" option), there's only so many times that I'll carefully type out my password blind before I decide to type it out where I can see it and then copy+paste it into the prompt. And again, if I didn't yet realize persistent undo tree history became turned on by default, I'd be inclined to use whatever buffer is most immediately accessible instead of switching first.

4. I might open a private key file in Emacs (which has properly locked-down read permissions and so on),

   1. maybe on accident (perhaps I was in a hurry, hit tab-completion on .ssh/id_, and sloppily hit enter before hitting another . TAB)
   2. maybe on purpose, to make/restore a key backup
   3. maybe as part of an eshell redirection from a keygen program into a file, which temporarily opens a buffer for that file which it then writes out (I don't know if that buffer gets normal persistent undo treatment, but if it just uses normal find-file to do it then I'd expect so, and in any case the security of my keys ideally wouldn't depend on me knowing that a redirection is actually implemented in an unusual way that combines with persisten undo-tree to work more like a tee).

   in the first case, the key only leaks if I then fat-finger certain keystrokes, but in the second and third the key just leaks in full (and the undo tree file gets permissions from the default umask instead of the more restrictive permissions of the original file! so your rw------- might turn into a rw-r--r--!)

5. On at least one occasion in my life, I intentionally pasted a password that had just been randomly generated into a file that I had open (without saving it, of course), and then later cut the password back a little later. I can't remember why - maybe I wanted or needed to copy-paste something without the delay of first getting the password into my password manager, or maybe I didn't have access to a password manager at the time so I just needed to hold onto the password and I didn't want it sitting in the clipboard (since I might've clobbered it and also way more programs could access it from clipboard than from an editor's memory).

All of these are relatively negligible possibilities individually, of course. But they're there, and they happen, and they add up to some risk that is worth more than zero mention in an issue dedicated to discussing the technical merits of having persistent history on by default.

And again, you can ask other to describe these possibilities for you (even though that's asking them to do more work than it would take you to think of them), or you can come at people so dismissively, but doing both is rude.

[lebensterben]

@mentalisttraceur

I asked a legit question and you may decide whether to answer it.

Instead you accuse me of being rude to you. What's wrong with you?

Compelling and realistic use cases are needed before making breaking changes.