Re: trusted-content seems to have effect only with sources specified.

[Eli Zaretskii <eliz@gnu.org>]

> From: Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>
> Date: Sat, 28 Dec 2024 20:12:27 +0100
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > It was done on purpose, yes:
> >
> >     (defun trusted-content-p ()
> >       "Return non-nil if we trust the contents of the current buffer.
> >     Here, \"trust\" means that we are willing to run code found inside of it.
> >     See also `trusted-content'."
> >       ;; We compare with `buffer-file-truename' i.s.o `buffer-file-name'
> >       ;; to try and avoid marking as trusted a file that's merely accessed
> >       ;; via a symlink that happens to be inside a trusted dir.
> >
> >> it will catch the case of a malicious symlink
> >> that redirects your trusted file/directory to a different place.
> >
> > In his case, the symlink presumably can't be malicious since it's inside
> > a trusted directory.  But I didn't want this trust to be transitive:
> > just because the symlink is non-malicious doesn't mean the target can't
> > contain things we can't control.  You may setup a perfectly valid symlink
> > to an area where you download random crap.
> Maybe this feature should be documented?
> `package-vc-install-from-checkout' is an api built-in emacs, that creates
> symbolic links.
> If an user tries to trust this "kind" of package, and it remains
> untrusted, her/him will switch to trust all the content.
> We should indicate that we have to use the true file name.

Isn't it obvious that trust should be given to actual files and
directories, not links to them?