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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 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: Sun, 15 Dec 2024 17:41:59 -0500

>> - The current setup is a kind of "minimal" change for Emacs-30 because
>>   it's late in the pretest, so as much as possible we should separate
>>   the discussion into what's a simple enough solution for Emacs-30 and
>>   what we should use in the longer term.
>
> Agree. As I suggested a simple trusted-buffer-function hook may be the
> simplest solution, which is also not limiting and allows us to mark
> various buffers as trusted.
>
>> - You should be able to get fully-featured Flymake in *scratch*
>>   with (setq-local trusted-files :all).
>>   Maybe we should do that when we setup *scratch*?
>>   Which other non-file buffers would need that?  The minibuffer?
>
> 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`.  ]

> Even more so since the variable is marked as risky local.

"Risky local" refers to file/dir-local settings, not
buffer-local settings.

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

> There we may be limited to trust, even if we want sandboxing in other
> scenarios.

Why?  What's different?

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

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.


        Stefan

Previous Next

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