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

Previous Next

Package: emacs;

Reported by: john muhl <jm <at> pub.pink>

Date: Sat, 21 Dec 2024 20:50:02 UTC

Severity: normal

Found in version 31.0.50

Full log


View this message in rfc822 format

From: john muhl <jm <at> pub.pink>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75017 <at> debbugs.gnu.org
Subject: bug#75017: 31.0.50; Untrusted user lisp files
Date: Sun, 22 Dec 2024 18:32:00 -0600
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: john muhl <jm <at> pub.pink>
>> Date: Sat, 21 Dec 2024 14:48:52 -0600
>> 
>> user-init-file is trusted by default but not other user files.
>> 
>>   C-xf ~/.emacs.d/early-init.el
>>   M-x flymake-mode
>> 
>> Produces a warning:
>> 
>>   Disabling elisp-flymake-byte-compile in early-init.el (untrusted content)
>> 
>> custom-file (when not the same as user-init-file) also causes a
>> warning. Should these also be trusted by default?
>
> No, not IMO.  Please add those files you know you can trust to the
> list of trusted files, and let's see if that works well for you.  If,
> after you have used that for some time, you have observations to
> report or changes to suggest, please do, but let's please base such
> observations on some sufficiently significant (read: long enough)
> experience.

Sure. That’s what I’ve done and it’ll certainly work for me. I
very rarely need to deal with untrusted files so of all Emacs
users I’ll be among those affected the least.

>> What about files put in place by a system admin or your distro’s
>> Emacs package (e.g. site-run-file, default.el)? They generally
>> require root priviledges to install so if they can’t be trusted
>> you’re already in trouble.
>
> On my system, these files do not need any admin privileges, so I don't
> think we should trust them by default.  Users who know that these
> files are modified only by trusted admins can and probably should add
> them to the list of trusted files, if they need that (in general,
> there should be no need to run Flymake in those files, in which case
> these files don't need to be added even if they are trusted).
>
> Btw, if we are talking about trusted admins, then entire directories
> should be trusted, for example /usr/share or /usr/share/emacs.
> There's a reason why we didn't do that by default.

Makes sense. These system files were a bit of a tangent to what
triggered this issue.

Specifically, I was surprised to find that user-init-file is
assumed safe but not early-init-file. After reading the
trusted-content part of the manual where it says “…which means no
file is trusted.” I assumed that included user-init-file. When I
saw that wasn’t the case I then assumed early-init-file would get
the same treatment. Maybe a little extra clarity there would be
sufficient for now.




This bug report was last modified 170 days ago.

Previous Next


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