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

[Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I discovered the issue, i think.
>>> Incidentally the packages i refer in `trusted-content' are installed via
>>> `package-vc-install-from-checkout', that generates a symlink in the
>>> directory in which we install our packages.
>>> If i specify in `trusted-content' the symlink, it generates the error.
>>> So we should specify only real paths.
>>
>> I think it's a feature:
>
> 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.
Regards,