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

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

[Michelangelo Rodriguez]

If i set `trusted-content' to:
"~/.emacs.d/elpa/elfeed/
And i visit say "elfeed.el",
and i enable `flymake-mode'
I get the following:
"""Disabling elisp-flymake-byte-compile in elfeed.el (untrusted
content)"
If i add "~/.emacs.d/elpa/elfeed/elfeed.el"
it works as expected.

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

[Eli Zaretskii]

> From: Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>
> Date: Fri, 27 Dec 2024 08:04:17 +0100
> 
> If i set `trusted-content' to:
> "~/.emacs.d/elpa/elfeed/
> And i visit say "elfeed.el",
> and i enable `flymake-mode'
> I get the following:
> """Disabling elisp-flymake-byte-compile in elfeed.el (untrusted
> content)"

I cannot reproduce this.  I don't have elfeed installed, but I used a
different file and subdirectory of ~/.emacs.d/, and didn't get the
disabling message.

Can you show the precise steps to reproduce the problem, starting from
"emacs -Q"?  Because at least the way you set trusted-content is not
clear to me: the value should be a list, but you say you set it to
"~/.emacs.d/elpa/elfeed/", which is a string.  Or maybe elfeed.el
loads files outside of the directory you declared to be safe?

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: Fri, 27 Dec 2024 08:04:17 +0100
>> 
>> If i set `trusted-content' to:
>> "~/.emacs.d/elpa/elfeed/
>> And i visit say "elfeed.el",
>> and i enable `flymake-mode'
>> I get the following:
>> """Disabling elisp-flymake-byte-compile in elfeed.el (untrusted
>> content)"
>
> I cannot reproduce this.  I don't have elfeed installed, but I used a
> different file and subdirectory of ~/.emacs.d/, and didn't get the
> disabling message.
>
> Can you show the precise steps to reproduce the problem, starting from
> "emacs -Q"?  Because at least the way you set trusted-content is not
> clear to me: the value should be a list, but you say you set it to
> "~/.emacs.d/elpa/elfeed/", which is a string.  Or maybe elfeed.el
> loads files outside of the directory you declared to be safe?
Sorry, i copied the contents of the customization buffer, but it is a
list.
The value is:
("~/.emacs.d/elpa/greader/greader.el" "~/.emacs.d/elpa/elfeed/")
With this value, i can enable flymake-mode in greader.el but not in
elfeed.el.
If i set '("~/.emacs.d/elpa/greader/") either in greader.el i get the
message.

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

[Michelangelo Rodriguez]

However, with a fresh session it works.
So it should depend from something i have in my configuration file, bug
what it could be?

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>
>> Date: Fri, 27 Dec 2024 08:04:17 +0100
>> 
>> If i set `trusted-content' to:
>> "~/.emacs.d/elpa/elfeed/
>> And i visit say "elfeed.el",
>> and i enable `flymake-mode'
>> I get the following:
>> """Disabling elisp-flymake-byte-compile in elfeed.el (untrusted
>> content)"
>
> I cannot reproduce this.  I don't have elfeed installed, but I used a
> different file and subdirectory of ~/.emacs.d/, and didn't get the
> disabling message.
>
> Can you show the precise steps to reproduce the problem, starting from
> "emacs -Q"?  Because at least the way you set trusted-content is not
> clear to me: the value should be a list, but you say you set it to
> "~/.emacs.d/elpa/elfeed/", which is a string.  Or maybe elfeed.el
> loads files outside of the directory you declared to be safe?

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

[Michelangelo Rodriguez]

There is the backtrace i get:
"Debugger entered--Lisp error: (error "Disabling elisp-flymake-byte-compile in greader.el (untrusted content)")
  error("Disabling elisp-flymake-byte-compile in %s (untrusted content)" "greader.el")
  elisp-flymake-byte-compile(#f(compiled-function (&rest args) #<bytecode -0x15eb6515a3691f83>))
  apply(elisp-flymake-byte-compile #f(compiled-function (&rest args) #<bytecode -0x15eb6515a3691f83>) nil)
  flymake--run-backend(elisp-flymake-byte-compile nil)
  #f(compiled-function (backend) #<bytecode -0x7f65577e7e0159b>)(elisp-flymake-byte-compile)
  flymake-start((on-display) nil)
  #f(compiled-function () #<bytecode 0x883a798531d0c11>)()
".
Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>
>> Date: Fri, 27 Dec 2024 08:04:17 +0100
>> 
>> If i set `trusted-content' to:
>> "~/.emacs.d/elpa/elfeed/
>> And i visit say "elfeed.el",
>> and i enable `flymake-mode'
>> I get the following:
>> """Disabling elisp-flymake-byte-compile in elfeed.el (untrusted
>> content)"
>
> I cannot reproduce this.  I don't have elfeed installed, but I used a
> different file and subdirectory of ~/.emacs.d/, and didn't get the
> disabling message.
>
> Can you show the precise steps to reproduce the problem, starting from
> "emacs -Q"?  Because at least the way you set trusted-content is not
> clear to me: the value should be a list, but you say you set it to
> "~/.emacs.d/elpa/elfeed/", which is a string.  Or maybe elfeed.el
> loads files outside of the directory you declared to be safe?

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

[Eli Zaretskii]

> From: Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>
> Date: Fri, 27 Dec 2024 10:39:39 +0100
> 
> However, with a fresh session it works.

In a fresh session with -Q or in a fresh session with your usual
configuration?  If the latter, then your customizations are not the
culprit.

> So it should depend from something i have in my configuration file, bug
> what it could be?

Try bisecting your init file(s), perhaps.

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

[Michelangelo Rodriguez]

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.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>
>> Date: Fri, 27 Dec 2024 08:04:17 +0100
>> 
>> If i set `trusted-content' to:
>> "~/.emacs.d/elpa/elfeed/
>> And i visit say "elfeed.el",
>> and i enable `flymake-mode'
>> I get the following:
>> """Disabling elisp-flymake-byte-compile in elfeed.el (untrusted
>> content)"
>
> I cannot reproduce this.  I don't have elfeed installed, but I used a
> different file and subdirectory of ~/.emacs.d/, and didn't get the
> disabling message.
>
> Can you show the precise steps to reproduce the problem, starting from
> "emacs -Q"?  Because at least the way you set trusted-content is not
> clear to me: the value should be a list, but you say you set it to
> "~/.emacs.d/elpa/elfeed/", which is a string.  Or maybe elfeed.el
> loads files outside of the directory you declared to be safe?

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

[Eli Zaretskii]

> From: Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>
> Date: Sat, 28 Dec 2024 00:02:54 +0100
> 
> 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 will catch the case of a malicious symlink
that redirects your trusted file/directory to a different place.

Stefan, do you agree?

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

[Stefan Monnier]

>> 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.


        Stefan

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

[Michelangelo Rodriguez]

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,

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

[Eli Zaretskii]

> 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?

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

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

[Stefan Monnier]

>> 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

Currently the error/warning message states the name of the buffer
(which is better because the trust can depend on other things than the
name of the associated file), but it would be helpful to include the
`buffer-file-truename` in the message to guide the user to the right
file/dir name to add to `trusted-content`.

Arguably, in many cases a better UI would be a bit like for
file/dir-local vars where we prompt the user whether to trust or not,
and if yes, whether to do it permanently (i.e. to add an entry to
`trusted-content` and `custom-save` the result).


        Stefan