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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mail@daniel-mendler.de, 74879@debbugs.gnu.org, monnier@iro.umontreal.ca,
>  stefankangas@gmail.com
> Date: Sun, 15 Dec 2024 12:50:41 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And can we really trust arbitrary ELisp code that to set trust?
> 
> When an arbitrary Elisp code is already running, there is nothing that
> can prevent that code from doing anything at all, including, for
> example, re-defining `trusted-content-p'. So, discussing whether we can
> trust a running Elisp code or not makes no sense in my book. We have to
> trust it.

"Arbitrary ELisp code" doesn't have to be malicious, just too
trusting.

> > And what about buffers whose contents came from a network connection?
> 
> The code that is putting text received from network connection should be
> responsible for marking the buffer appropriately.

How can that work in practice?  What can that code do to know whether
the stuff can or cannot be trusted?

> > What about buffers whose contents came from inserting some file or
> > part thereof, or were generated by processing some file?
> 
> Again, the code should be responsible to check things, maybe using some
> kind of API function to check whether a given source file should be
> trusted or not.
> 
> > What about buffers whose contents came from a program Emacs invoked?
> 
> Same thing.
> I'd say that the codes receiving text contents from network or from a
> program should not mark it as trusted.

Now we are getting somewhere.

My point is that we should probably not leave this open to some
function, but instead code our own ways of deciding whether a given
buffer is trusted.

> One alternative might be storing "trust flag" as text property for Emacs
> primitives that read file contents, network stream, or program
> output. Then, if any part of buffer has "trust flag" set to be not
> trusted, the whole buffer should not be considered trusted.

My problem is not how NOT to trust, my problem is in which cases to
trust.  Saying that by default such buffers are not trusted is easy --
we already do that, in fact.