GNU bug report logs - #74879
30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers

Previous Next

Full log

Message #113 received at 74879 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74879 <at> debbugs.gnu.org
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be
 used for non-file buffers
Date: Sat, 11 Jan 2025 01:56:01 -0800

Dmitry Gutov <dmitry <at> gutov.dev> writes:

>> - I think we do want some kind of hook, with which we can have (for
>>    instance) `emacs-lisp-mode` tell Emacs to trust the user init file,
>>    the early-init file, the custom-file, and all the files in
>>    `load-path`.
>
> Speaking of, it would be nice to see someone formulate the thread model
> we're trying to handle this way.

No one did that, as far as I know.

In informal terms, the main problem is files you download online (e.g.,
from a website or in a Git repository), that could come from a
potentially malicious source.

OTOH, `trusted-files' does not really do anything to protect against
malicious ELPA packages.  We need to start compiling them in a sandbox
(e.g., bwrap), and it's likely that we'll also need to take some special
precautions with autoloads.  But this is well-known and documented
already, I think.

> Indeed, should add files in load-path be considered "trusted"? If yes,
> why not do this automatically. If no, then what do we think about a
> scenario when a "trusted" file ends up loading a file from load-path
> which redefines some standard macro.

I haven't seen any arguments for why we shouldn't mark files in
`load-path' trusted, so my guess is that the answer is "yes".

I couldn't give you a solid reason for why we're not already doing this
automatically, myself.  However, there is clearly a difference between
malicious code running when loading a file, and when merely visiting it.

Previous Next

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