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 Monnier <monnier <at> iro.umontreal.ca>
Cc: 74879 <at> debbugs.gnu.org
Subject: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers
Date: Mon, 16 Dec 2024 10:29:41 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Given that the trust applies to the given buffer, setting `(setq-local
>> trusted-files :all)' in this buffer feels odd as
>> a recommended mechanism.
>
> I can live with that for now.
> It's probably not much worse than
>
>     (add-function :override (local 'trusted-content-function) #'always)
>
> [ BTW, I just renamed the var to `trusted-content`.  ]

I think it is not as good as a central configuration variable where I
configure the trust for buffers or files. Now configuring trust is
scattered across multiple major modes. My proposal was for a global hook
variable which is consulted by `trusted-content-p' and then checks
certain trust list for files or buffers. This way it is easier to check
what we are trusting.

>>> - Trust sucks, so we really should work on better solutions where we
>>>   don't need to rely on trust, such as running code in `bwrap` or other
>>>   kinds of sandboxes.
>> I agree. But what about interactive scenarios like auto completion?
>
> I don't understand the question.

I mean that not all of the scenarios can be run in some sandbox. If we
cannot put all Capfs in a sandbox we could at least prevent auto
completion entirely based on trust.

>> I think trust checking might be helpful in all scenarios where there
>> is a "low threshold" to invoking code execution or
>> even unintentionally.
>
> Oh, you mean for code completion we don't want to incur the cost of
> spawning a subprocess?  Indeed that can be a reason to fallback to trust.

The thought was rather that auto completion may be dangerous in general
and since it is triggered with a low threshold one could prevent auto
completion right away. I think you have a more fine-grained model in mind
where certain macros are trusted and so on.

> But note that in the "other kinds of sandboxes" I include things like
> labeling macros with some indication about how they can be run safely,
> so we can have a version of `elisp--safe-macroexpand-all` which does
> something useful even if the buffer's content is not trusted.
>
>>> - 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`.
>>
>> You suggest a hook which is executed per buffer? This seems similar to
>> my proposal of a `trusted-buffer-function` hook.
>
> Yes, that's exactly what I was referring to.
> At first I was thinking of some kind of `trusted-buffer-functions` hook
> used with `run-hook-with-args-until-success`, but I think you're right
> that it's better to go with `trusted-buffer-function` so we can both add
> and remove trust with it.

My initial proposal was about a global `trusted-buffer-functions' hook
but I may have not communicated this clearly enough. I have two problems
with the buffer-local approach:

1. I find it difficult to check what we are trusting, since the trust
settings are scattered over multiple files.

2. How can I configure certain buffers to be trusted? One could
configure `trusted-content' at the time of buffer creation. Or is there
a hook which you suggest to use? Right now it seems that the idea is to
set `trusted-content` based on major modes?

Daniel

Previous Next

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