bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers

[Eli Zaretskii <eliz@gnu.org>]

> From: Daniel Mendler <mail@daniel-mendler.de>
> Cc: 74879@debbugs.gnu.org,  monnier@iro.umontreal.ca,  stefankangas@gmail.com
> Date: Sun, 15 Dec 2024 11:56:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What do you envision trusted-buffer-function should do in a buffer
> > that doesn't visit a file?
> 
> `trusted-buffer-function' should be a hook variable, which could be set
> to multiple functions, e.g., #'trusted--files-p and
> #'trusted--buffers-p. The function `trusted--files-p' would check the
> variable `trusted-files' similar to the existing code in the emacs-30
> branch.

I was asking specifically about the non file-visiting buffers.

> The function `trusted--buffers-p' could check another variable
> `trusted-buffers' which specifies a list of buffer name regexps or
> probably even better a `buffer-match-p' condition. This way the user
> could specify buffers which they consider safe, for example *scratch*.

Why would a buffer's name tell _anything_ about whether the user can
trust it?

> In the end it is up to the user how the variables are configured, as is
> already the case with `trusted-files'. The user must define which
> directories/files/buffers they consider safe.

If we wanted to let this completely up to the user, we wouldn't be
introducing this feature, certainly not so close to a release, would
we?

The question is serious: how do we envision this "trust" thing to work
with buffers that don't visit files?  If we are to change the code,
certainly on the emacs-30 branch, we need a solid solution which
provides more safety/security to users.  Adding a variable doesn't
solve a problem, it _adds_ a problem (how to populate the variable).