From: Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: 74879@debbugs.gnu.org
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
Stefan Kangas <stefankangas@gmail.com>
Subject: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers
Date: Sun, 15 Dec 2024 11:16:17 +0100 [thread overview]
Message-ID: <875xnlfdzi.fsf@daniel-mendler.de> (raw)
In-Reply-To: <87ed29ixu8.fsf@daniel-mendler.de> (Daniel Mendler's message of "Sun, 15 Dec 2024 01:39:11 +0100")
Daniel Mendler <mail@daniel-mendler.de> writes:
> Thank you for the recent addition of `trusted-content-p'. Is there a
> possibility to use `trusted-content-p' in buffers which are not backed
> by a file? I use Flymake in *scratch* or similar buffers and it seems
> that this won't continue to work given that `trusted-content-p' needs a
> `buffer-file-truename'.
>
> My suggestion would be to replace `trusted-files' by a
> `trusted-buffer-function' which is a predicate function or a list of
> functions. The functions could then check a custom list of trusted files
> or a custom list of trusted buffers.
>
> Alternatively offer `trusted-files', `trusted-buffers' and
> `trusted-buffer-function`? `trusted-buffers' could for example rely on
> `buffer-match-p`.
I have also ported back `trusted-content-p' via Compat. I had the plan
to use `trusted-content-p' in external packages which could potentially
perform dangerous operations. This way the new feature can be used to
retroactively improve the safety even of older Emacs installations.
For example in my GNU ELPA Corfu package the plan was to check
`(trusted-content-p)' when starting auto completion. To be clear - Corfu
is safe by default, since auto completion is disabled by default.
However many people enable auto completion unconditionally in all
buffers.
Now with the limitation of `trusted-content-p' to file-backed buffers, I
cannot do this, since otherwise auto completion would be lost for
example in *scratch* buffers. Each package could invent its own trust
mechanism or alternatively one could limit the `trusted-content-p' check
to only file-backed buffers. Both alternatives would be worse than going
through the `trusted-content-p' standard mechanism.
Therefore by making the `trusted-content-p' mechanism too limited, we
get less safety than with a more flexible mechanism. Nevertheless I
would avoid creating a complex mechanism given that the mechanism is
supposed to be part of Emacs 30. The simplest approach I can think of
this this `trusted-buffer-function', a hook called by
`run-hook-with-args-until-success'. Later on trust functions can be
provided and added to the hook list. The trust functions could check
file lists, buffer lists, regexps etc. Users can also write their own
predicate functions.
In any case, I am happy to help providing patches.
Daniel
next prev parent reply other threads:[~2024-12-15 10:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-15 0:39 bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-15 10:16 ` Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-12-15 10:47 ` Eli Zaretskii
2024-12-15 10:56 ` Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-15 11:18 ` Eli Zaretskii
2024-12-15 11:37 ` Ihor Radchenko
2024-12-15 12:29 ` Eli Zaretskii
2024-12-15 12:50 ` Ihor Radchenko
2024-12-15 13:38 ` Eli Zaretskii
2024-12-15 13:46 ` Stefan Kangas
2024-12-15 14:03 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-15 14:30 ` Stefan Kangas
2024-12-15 14:55 ` Gerd Möllmann
2024-12-15 15:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-15 15:16 ` Gerd Möllmann
2024-12-15 18:38 ` Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xnlfdzi.fsf@daniel-mendler.de \
--to=bug-gnu-emacs@gnu.org \
--cc=74879@debbugs.gnu.org \
--cc=mail@daniel-mendler.de \
--cc=monnier@iro.umontreal.ca \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).