bug#75017: 31.0.50; Untrusted user lisp files

bug#75017: 31.0.50; Untrusted user lisp files

[john muhl]

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?

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.




In GNU Emacs 31.0.50 (build 87, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.2) of 2024-12-21 built on thelio
 Repository revision: ff4fcfc92cd80c9dbc68855549102d07ef419268
 Repository branch: master
 System Description: Fedora
 Linux 41 (Workstation Edition)

Configured using:
 'configure --with-pgtk --prefix=/home/jm/opt'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS
TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  server-mode: t
  bug-reference-prog-mode: t
  bug-reference-mode: t
  completion-preview-mode: t
  outline-minor-mode: t
  ruler-mode: t
  winner-mode: t
  savehist-mode: t
  repeat-mode: t
  midnight-mode: t
  global-visual-wrap-prefix-mode: t
  visual-wrap-prefix-mode: t
  global-paren-face-mode: t
  paren-face-mode: t
  global-goto-address-mode: t
  goto-address-mode: t
  global-auto-revert-mode: t
  electric-pair-mode: t
  dynamic-completion-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  auto-insert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-quote-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  auto-save-visited-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug magit-utils crm dash misearch
multi-isearch texinfo texinfo-loaddefs tex-mode compare-w
make-mode css-mode smie sgml-mode facemenu imenu eww vtable
url-queue shr pixel-fill kinsoku url-file svg xml dom mm-url gnus
message sendmail yank-media puny rfc822 mml mml-sec epa epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
nnheader gnus-util mail-utils range mm-util mail-prsvr color
python skeleton cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-langs cc-vars cc-defs cc-bytecomp
c++-ts-mode c-ts-mode c-ts-common mule-util dired-aux dired-x
dired dired-loaddefs lua-ts-mode treesit flymake server warnings
tabify fennel-mode xref project inf-lisp shell pcomplete shortdoc
help-fns radix-tree cl-print debug backtrace find-func apropos
cursor-sensor compile text-property-search comint ansi-osc
ansi-color comp-run comp-common smerge-mode diff disp-table
whitespace emacs-news-mode time-date vc-git diff-mode
track-changes derived files-x vc-dir ewoc vc vc-dispatcher
bug-reference completion-preview easy-mmode pcase noutline outline
ruler-mode specter-theme auth-source-pass winner ring savehist
repeat midnight visual-wrap paren-face compat goto-addr thingatpt
cl-extra help-mode autorevert filenotify elec-pair completion
desktop frameset delsel autoinsert cus-start time init
fennel-mode-autoloads magit-autoloads git-commit-autoloads
dash-autoloads magit-section-autoloads paren-face-autoloads
finder-inf info with-editor-autoloads xr-autoloads package
browse-url xdg url url-proxy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
password-cache json map byte-opt gv bytecomp byte-compile
url-privacy url-vars early-init rx subr-x cus-edit pp cus-load
icons wid-edit cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
touch-screen pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer
select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face
macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk
pgtk multi-tty move-toolbar make-network-process tty-child-frames
native-compile emacs)

Memory information:
((conses 16 4219242 387989) (symbols 48 31297 4)
 (strings 32 279165 15056) (string-bytes 1 12853103)
 (vectors 16 57830) (vector-slots 8 656011 595942) (floats 8 646 3216)
 (intervals 56 848446 3470) (buffers 992 79))

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

john muhl <jm@pub.pink> writes:

> 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?
>
> 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.

Makes sense to me.

Maybe we should install something like the below?

diff --git a/lisp/files.el b/lisp/files.el
index c92fc0608dd..293f3c59c0d 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -748,10 +748,16 @@ trusted-content-p
          (with-demoted-errors "trusted-content-p: %S"
            (let ((exists (file-exists-p buffer-file-truename)))
              (or
-              ;; We can't avoid trusting the user's init file.
-              (if (and exists user-init-file)
-                  (file-equal-p buffer-file-truename user-init-file)
-                (equal buffer-file-truename user-init-file))
+              ;; We can't avoid trusting the user's init file, etc.
+              (memq t
+                    (mapcar
+                     (lambda (file)
+                       (if (and exists file)
+                           (file-equal-p buffer-file-truename file)
+                         (equal buffer-file-truename file)))
+                     (list user-init-file
+                           early-init-file
+                           site-run-file)))
               (let ((file (abbreviate-file-name buffer-file-truename))
                     (trusted nil))
                 (dolist (tf trusted-content)

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Maybe we should install something like the below?

Fine by me, but I think this should be added via a new
`trusted-content-function(s)` and added buffer-locally only in
elisp-mode buffers.


        Stefan

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: john muhl <jm@pub.pink>,  75017@debbugs.gnu.org,  Eli Zaretskii
>  <eliz@gnu.org>,  Andrea Corallo <acorallo@gnu.org>
> Date: Sat, 21 Dec 2024 22:16:05 -0500
> 
> > Maybe we should install something like the below?
> 
> Fine by me, but I think this should be added via a new
> `trusted-content-function(s)` and added buffer-locally only in
> elisp-mode buffers.

Sorry, but this is slippery slope.  For starters, no one said that
site-run-file is installed by a sysadmin -- that is only so on certain
systems.  For example, MS-Windows is generally not in that category.

More generally, if we go this way, i.e. every complaint by some user
about a file that _could_ be trusted, or even is trusted on a group of
systems, causes us to add more and more files and directories to the
trusted list, there will be no end to this, and, significantly, Emacs
30 will never be released.

So from where I stand, what we have now on the latest emacs-30 branch
is as good and as far as it gets, at least for Emacs 30.  My
suggestion to anyone who wants additional files/directories to vet to
please use the existing facilities to add them to the trusted list.
This way, we collect experience and data points regarding which
files/directories and under what conditions should be trusted, and can
improve what we have now in the future.  At that future time we should
probably ask users to name the files and directories they needed to
add to the trusted list, and take it from there, making changes which
will take that into account.

If you still insist on installing such changes at this time, please do
that on master.  My preference is to wait with this until we have
enough experience with what we have, which means not before Emacs 30.1
is released and a couple of months go by.  But if people insist on
installing now on master, I won't object.

Thanks.

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: john muhl <jm@pub.pink>,  75017@debbugs.gnu.org,  Eli Zaretskii
>>  <eliz@gnu.org>,  Andrea Corallo <acorallo@gnu.org>
>> Date: Sat, 21 Dec 2024 22:16:05 -0500
>>
>> > Maybe we should install something like the below?
>>
>> Fine by me, but I think this should be added via a new
>> `trusted-content-function(s)` and added buffer-locally only in
>> elisp-mode buffers.
>
> Sorry, but this is slippery slope.  For starters, no one said that
> site-run-file is installed by a sysadmin -- that is only so on certain
> systems.  For example, MS-Windows is generally not in that category.

It doesn't matter who can edit it.  `site-run-file` is already trusted,
since it is loaded at run-time before `user-init-file`.

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 22 Dec 2024 17:36:15 +0000
> Cc: jm@pub.pink, 75017@debbugs.gnu.org, acorallo@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: john muhl <jm@pub.pink>,  75017@debbugs.gnu.org,  Eli Zaretskii
> >>  <eliz@gnu.org>,  Andrea Corallo <acorallo@gnu.org>
> >> Date: Sat, 21 Dec 2024 22:16:05 -0500
> >>
> >> > Maybe we should install something like the below?
> >>
> >> Fine by me, but I think this should be added via a new
> >> `trusted-content-function(s)` and added buffer-locally only in
> >> elisp-mode buffers.
> >
> > Sorry, but this is slippery slope.  For starters, no one said that
> > site-run-file is installed by a sysadmin -- that is only so on certain
> > systems.  For example, MS-Windows is generally not in that category.
> 
> It doesn't matter who can edit it.  `site-run-file` is already trusted,
> since it is loaded at run-time before `user-init-file`.

It is loaded if it is there.  On my system, there's no such file, and
I don't expect to have it.  So if such a file somehow materializes
there, I want to know, pronto.

bug#75017: 31.0.50; Untrusted user lisp files

[Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors]

(Apologies for not following this thread.)

If this is about Emacs claiming/suggesting
that something is trusted or untrusted, I'd
say we're better off saying only that Emacs
CANNOT vouch for the thing to be trusted.

That's better than claiming that something
can't be trusted.  And it's _much_ better
than claiming that something _can_ be trusted.

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: john muhl <jm@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.

> 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.

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: john muhl <jm@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.
>
>> 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).

I don't think it's meaningful to consider them as not
`trusted-content-p`, when we automatically load these files into any
running Emacs session.

> Btw, if we are talking about trusted admins, then entire directories
> should be trusted, for example /usr/share or /usr/share/emacs.

Yes, though we'd have to discuss which directories those are;
`load-path` and `source-directory` are two candidates.

> There's a reason why we didn't do that by default.

My understanding is that we just didn't consider all of these cases.
At least I didn't.

If others did, it wasn't sufficiently explicit for me to notice.

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 22 Dec 2024 17:20:13 +0000
> Cc: 75017@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> >
> >> 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).
> 
> I don't think it's meaningful to consider them as not
> `trusted-content-p`, when we automatically load these files into any
> running Emacs session.

No, we don't load anything.  It's the user who tells us whether to
load these files, by placing them in those locations and naming them
according to what Emacs looks for.  It's up to the user to tell us
whether everything in those files is trustworthy.

And let's not forget that various packages write to the init files, so
not everything there was written by the user.

bug#75017: 31.0.50; Untrusted user lisp files

[Dmitry Gutov]

On 22/12/2024 20:38, Eli Zaretskii wrote:
> And let's not forget that various packages write to the init files, so
> not everything there was written by the user.

And Emacs will load whatever's written there on the next restart. 
Whether the user wrote to those files, or someone else.

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> Date: Sun, 22 Dec 2024 21:52:28 +0200
> Cc: jm@pub.pink, 75017@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 22/12/2024 20:38, Eli Zaretskii wrote:
> > And let's not forget that various packages write to the init files, so
> > not everything there was written by the user.
> 
> 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..?

bug#75017: 31.0.50; Untrusted user lisp files

[Dmitry Gutov]

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.

bug#75017: 31.0.50; Untrusted user lisp files

[john muhl]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: john muhl <jm@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.