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

[Michelangelo Rodriguez]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?
Yes, what is not obvious is to think that the problem is caused by
symbolic links