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