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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Wed, 25 Dec 2024 01:29:36 +0200

On 23/12/2024 14:31, 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

Thank you. So the scenario where we would make the distinction is when 
the user managed to notice (somehow?) that the file had changed during 
the Emacs session, and then went to edit it.

To be frank, I asked the question after reading the scenario from the 
first message, and it talks about early-init-file. IIUC this file lives 
in the same dir as the plain user-init-file, so the chances of them 
being edited by someone other than the user should be about equal, and 
we do "trust" the latter file automatically.

Probably not too critical, but inconsistencies can be annoying (the user 
has to spend time figuring out whether something is broken and why).

Previous Next

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