GNU bug report logs - #75017
31.0.50; Untrusted user lisp files

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: jm <at> pub.pink, stefankangas <at> gmail.com, 75017 <at> debbugs.gnu.org
Subject: bug#75017: 31.0.50; Untrusted user lisp files
Date: Mon, 23 Dec 2024 14:31:08 +0200

> Date: Sun, 22 Dec 2024 22:27:34 +0200
> Cc: stefankangas <at> gmail.com, jm <at> pub.pink, 75017 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 22/12/2024 22:23, Eli Zaretskii wrote:
> >> And Emacs will load whatever's written there on the next restart.
> >> Whether the user wrote to those files, or someone else.
> > Yes, and your point is..?
> 
> That whatever malicious code we try to protect against using the 
> "trusted content" mechanism would be executed anyway.

The scenario I have in mind is this:

  . Emacs session is running; when it was started, there was no
    site-init file
  . User notices that site-init file appeared
  . User visits the site-init file
  . Malicious macro in site-init file is executed

IOW, there could be valid situations where the user visits the file
before restarting Emacs (which would load the file).  In these
situations, it would make sense to treat the file as not trusted --
unless the user tells us it should always be unconditionally trusted.

IMO, we should only make files and directories trusted by default if
we are either 100% sure they can never be malicious, or 100% sure they
will always be loaded before they are visited.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.