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

View this message in rfc822 format

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

Stefan Kangas <stefankangas <at> gmail.com> writes:

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

If I understood Stefan Monnier's bwrap suggestion correctly, it was
about evaluating macros of untrusted Elisp code from an unknown source
somewhere on the file system. ELPA packages can be trusted more for
multiple reasons:

1. They come from known sources, from curated archives. Admittedly the
archive review is not sufficient. I've suggested to add review
facilities to package.el, see bug#74604. Furthermore I've suggested to
add git commit signature checks to GNU/NonGNU ELPA, see bug#61277.

2. There is the barrier of adding untrusted archives to the
`package-archives' list. The user has to opt-in explicitly to that.

3. Installation of packages is confirmed via package.el and does not
happen without user consent.

As soon as the user agrees to install a package, they agree that the
package will shortly become part of the `load-path', and that its code
will be executed shortly. If we believe that package installation is not
safe enough, additional louder confirmations and warnings could be
added: When adding new archives (additional validation of
`package-archives') and second and when installing or upgrading
packages. For example `package-upgrade-all' tells me how many packages
it wants to upgrade but not even which packages - I really want to
inspect the list of upgradeable packages first.

Which additional benefits do you see if ELPA packages are compiled
inside bwrap? The trust will only be pushed a little to the future. Then
additional confirmation will be needed for the autoloads and not much is
won. As soon as an autoload is confirmed, the package is trusted.
Instead of doing that, asking the user earlier (before download and
latest before compilation) is as good or even better since then the
untrusted code does not even hit the ~/.emacs.d/elpa directory. See in
particular bug#74604, where the quick review could happen before
installation.

Daniel

Previous Next

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