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 #128 received at 74879 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 74879 <at> debbugs.gnu.org,
 Dmitry Gutov <dmitry <at> gutov.dev>
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 09:30:06 -0500

[Message part 1 (text/x-markdown, inline)]

>> As I argued, using bwrap for package compilation will not yield
>> additional security benefits, since this will only push the confirmation
>> slightly to the future, to the time when the package is loaded.
> "Slightly to the future" could be "never" if the package is unused.
> (Assuming that we also do something about autoloading.)

We'd need to do more than "something about autoloading": a malicious
php-mode package could come with a `python.el(c)` file.

Reducing the potential for harm from installed ELisp packages is
not a bad idea, but it's hard.

Also, while some packages like php-mode can naturally be confined to
special cases, others are harder to confine and many of those others are
written under the assumption that if you have installed it it's because
you want to use it almost always, so they make no effort to load lazily.

> While I like some of your ideas, the point that I was making is simply
> that it would be better if ELisp compilation took place in a safe
> sandbox.  I don't claim that this will fix all security issues, but only
> that it will specifically fix one issue: code from packages or visited
> files would no longer run with the same privileges as Emacs when
> installing packages or with flymake.

Of course, that will tend to break those packages which use their ELisp
compilation to build their C module.


        Stefan

Previous Next

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