GNU bug report logs - #77666
Question/discussion about `trusted-content'

Previous Next

To reply to this bug, email your comments to 77666 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
To: "Emacs Bug Tracker" <bug-gnu-emacs <at> gnu.org>
Subject: Question/discussion about `trusted-content'
Date: Wed, 09 Apr 2025 09:33:41 +0200

Hello,

I have a remark/question with respect to the newly introduced
`trusted-content' customizable variable. The documentation states

    - If it ends in "/", it is considered as a directory name and means that
      Emacs should trust all the files whose name has this directory as a prefix.

And then,

    Use abbreviated file names.  For example, an entry "~/mycode/" means
    that Emacs will trust all the files in your directory "mycode".

Why is this second requirement in place?

I tried trusting a directory using an absolute file name, e.g.,
"/home/user/trusted/dir/", and failed! I think this is because Emacs
uses the `buffer-file-truename' variable to check if the file is
trusted, and `buffer-file-truename' is "~/trusted/dir/basename".

That is, I had to set `trusted-content' to a list containing
"~/trusted/dir/" which I want to avoid. Isn't it safer to trust absolute
directories instead of directories relative to the user home directory?

On the side, isn't the name `buffer-file-truename' a misnomer? The
"true" ("real", see `realpath') filename should be the absolute one, or
not? What am I missing here?

Thanks for your consideration.

Dominik

Message #8 received at 77666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dominik Schrempf <dominik.schrempf <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 77666 <at> debbugs.gnu.org
Subject: Re: bug#77666: Question/discussion about `trusted-content'
Date: Wed, 09 Apr 2025 15:40:14 +0300

> From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
> Date: Wed, 09 Apr 2025 09:33:41 +0200
> 
> I have a remark/question with respect to the newly introduced
> `trusted-content' customizable variable. The documentation states
> 
>     - If it ends in "/", it is considered as a directory name and means that
>       Emacs should trust all the files whose name has this directory as a prefix.
> 
> And then,
> 
>     Use abbreviated file names.  For example, an entry "~/mycode/" means
>     that Emacs will trust all the files in your directory "mycode".
> 
> Why is this second requirement in place?

For speed, I believe.  (But Stefan will correct me if I'm wrong.)

> I tried trusting a directory using an absolute file name, e.g.,
> "/home/user/trusted/dir/", and failed! I think this is because Emacs
> uses the `buffer-file-truename' variable to check if the file is
> trusted, and `buffer-file-truename' is "~/trusted/dir/basename".

Exactly.

> That is, I had to set `trusted-content' to a list containing
> "~/trusted/dir/" which I want to avoid.

Why do you want to avoid it?

> Isn't it safer to trust absolute
> directories instead of directories relative to the user home directory?

HOME-relative file names are considered absolute file names in Emacs:

  (file-name-absolute-p "~/.emacs.d/")
   => t

> On the side, isn't the name `buffer-file-truename' a misnomer? The
> "true" ("real", see `realpath') filename should be the absolute one, or
> not? What am I missing here?

See above.

Emacs always abbreviates HOME-relative file names, so adhering to that
convention means we can compare file names as strings, instead of
using file-truename (which hits the disk) and similar APIs to
"normalize" the file names before comparing.

Message #11 received at 77666 <at> debbugs.gnu.org (full text, mbox):

From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77666 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77666: Question/discussion about `trusted-content'
Date: Wed, 09 Apr 2025 16:22:58 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
>> Date: Wed, 09 Apr 2025 09:33:41 +0200
>>
>> I have a remark/question with respect to the newly introduced
>> `trusted-content' customizable variable. The documentation states
>>
>>     - If it ends in "/", it is considered as a directory name and means that
>>       Emacs should trust all the files whose name has this directory as a prefix.
>>
>> And then,
>>
>>     Use abbreviated file names.  For example, an entry "~/mycode/" means
>>     that Emacs will trust all the files in your directory "mycode".
>>
>> Why is this second requirement in place?
>
> For speed, I believe.  (But Stefan will correct me if I'm wrong.)

Do you mean comparing "/home/user/mycode" is slower than comparing
"~/mycode/"? That doesn't make much sense to me, but I may miss relevant
information.

>
>> I tried trusting a directory using an absolute file name, e.g.,
>> "/home/user/trusted/dir/", and failed! I think this is because Emacs
>> uses the `buffer-file-truename' variable to check if the file is
>> trusted, and `buffer-file-truename' is "~/trusted/dir/basename".
>
> Exactly.
>
>> That is, I had to set `trusted-content' to a list containing
>> "~/trusted/dir/" which I want to avoid.
>
> Why do you want to avoid it?

I guess the reason is caution. I had situations where the tilde was not
expanded and a file was not found. I do not think this was in Emacs, but
that's how habits are formed.

>
>> Isn't it safer to trust absolute
>> directories instead of directories relative to the user home directory?
>
> HOME-relative file names are considered absolute file names in Emacs:
>
>   (file-name-absolute-p "~/.emacs.d/")
>    => t

Thank you, I didn't know that. Does this make sense? The file will be
different for two different users, which is not the case for absolute
file names in the classical sense.

>
>> On the side, isn't the name `buffer-file-truename' a misnomer? The
>> "true" ("real", see `realpath') filename should be the absolute one, or
>> not? What am I missing here?
>
> See above.
>
> Emacs always abbreviates HOME-relative file names, so adhering to that
> convention means we can compare file names as strings, instead of
> using file-truename (which hits the disk) and similar APIs to
> "normalize" the file names before comparing.

Thanks for your explanation.

I believe that by now, we are having a discussion about two different
but somewhat related concepts: "absolute" vs "relative" filenames and
the "true" vs "real" filenames.

I still wanted to state that the term "true filename" confused me and is
still confusing me. I think it should be "real", at least to me this
seems more of a Linux/Unix? standard.

Thanks!

Message #14 received at 77666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dominik Schrempf <dominik.schrempf <at> gmail.com>
Cc: 77666 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#77666: Question/discussion about `trusted-content'
Date: Wed, 09 Apr 2025 18:44:14 +0300

> From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  77666 <at> debbugs.gnu.org
> Date: Wed, 09 Apr 2025 16:22:58 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >>     Use abbreviated file names.  For example, an entry "~/mycode/" means
> >>     that Emacs will trust all the files in your directory "mycode".
> >>
> >> Why is this second requirement in place?
> >
> > For speed, I believe.  (But Stefan will correct me if I'm wrong.)
> 
> Do you mean comparing "/home/user/mycode" is slower than comparing
> "~/mycode/"?

No, but comparing "~/mycode" with "/home/user/mycode" is slower, if we
want them to compare equal.

> > HOME-relative file names are considered absolute file names in Emacs:
> >
> >   (file-name-absolute-p "~/.emacs.d/")
> >    => t
> 
> Thank you, I didn't know that. Does this make sense? The file will be
> different for two different users, which is not the case for absolute
> file names in the classical sense.

There's only one user in a given Emacs session.

Outside of Emacs, these will be different file names, but since Emacs
always records the abbreviated name, it will become ~/something only
for the user of the current Emacs session; file names relative to HOME
of other users will remain in their absolute form.

> > Emacs always abbreviates HOME-relative file names, so adhering to that
> > convention means we can compare file names as strings, instead of
> > using file-truename (which hits the disk) and similar APIs to
> > "normalize" the file names before comparing.
> 
> Thanks for your explanation.
> 
> I believe that by now, we are having a discussion about two different
> but somewhat related concepts: "absolute" vs "relative" filenames and
> the "true" vs "real" filenames.
> 
> I still wanted to state that the term "true filename" confused me and is
> still confusing me. I think it should be "real", at least to me this
> seems more of a Linux/Unix? standard.

Emacs predates realpath and friends, so we had this terminology first,
and we cannot change it now, since it's so old.

Message #17 received at 77666 <at> debbugs.gnu.org (full text, mbox):

From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77666 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#77666: Question/discussion about `trusted-content'
Date: Thu, 10 Apr 2025 04:33:46 +0200

Thank you for taking your time to answer my questions!

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  77666 <at> debbugs.gnu.org
>> Date: Wed, 09 Apr 2025 16:22:58 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >>     Use abbreviated file names.  For example, an entry "~/mycode/" means
>> >>     that Emacs will trust all the files in your directory "mycode".
>> >>
>> >> Why is this second requirement in place?
>> >
>> > For speed, I believe.  (But Stefan will correct me if I'm wrong.)
>>
>> Do you mean comparing "/home/user/mycode" is slower than comparing
>> "~/mycode/"?
>
> No, but comparing "~/mycode" with "/home/user/mycode" is slower, if we
> want them to compare equal.

I think this problem would not arise if Emacs treated all filenames as
"completely"/"truly (:-))" (no pun intended) absolute. In my opinion,
and without knowing many details about the interior design of Emacs,
this would probably also be the ideal situation.

>
>> > HOME-relative file names are considered absolute file names in Emacs:
>> >
>> >   (file-name-absolute-p "~/.emacs.d/")
>> >    => t
>>
>> Thank you, I didn't know that. Does this make sense? The file will be
>> different for two different users, which is not the case for absolute
>> file names in the classical sense.
>
> There's only one user in a given Emacs session.
>
> Outside of Emacs, these will be different file names, but since Emacs
> always records the abbreviated name, it will become ~/something only
> for the user of the current Emacs session; file names relative to HOME
> of other users will remain in their absolute form.
>
>> > Emacs always abbreviates HOME-relative file names, so adhering to that
>> > convention means we can compare file names as strings, instead of
>> > using file-truename (which hits the disk) and similar APIs to
>> > "normalize" the file names before comparing.
>>
>> Thanks for your explanation.
>>
>> I believe that by now, we are having a discussion about two different
>> but somewhat related concepts: "absolute" vs "relative" filenames and
>> the "true" vs "real" filenames.
>>
>> I still wanted to state that the term "true filename" confused me and is
>> still confusing me. I think it should be "real", at least to me this
>> seems more of a Linux/Unix? standard.
>
> Emacs predates realpath and friends, so we had this terminology first,
> and we cannot change it now, since it's so old.

Good to know, thank you.

In your opinion, what is the reason of why we can not change such names?
Is this because (1) we do not have enough resources to change such
discrepancies in nomenclature, or (2) because we are not willing to
change nomenclature, or (3) we must ensure backwards compatibility?

(I just grepped for "truename" in the Emacs repository and got 942 hits).

Independently of what we can change or not, I think it is important to
reduce discrepancies in nomenclature. Thanks for hearing me out!

Message #20 received at 77666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dominik Schrempf <dominik.schrempf <at> gmail.com>
Cc: 77666 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#77666: Question/discussion about `trusted-content'
Date: Thu, 10 Apr 2025 10:41:19 +0300

> From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca,  77666 <at> debbugs.gnu.org
> Date: Thu, 10 Apr 2025 04:33:46 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Do you mean comparing "/home/user/mycode" is slower than comparing
> >> "~/mycode/"?
> >
> > No, but comparing "~/mycode" with "/home/user/mycode" is slower, if we
> > want them to compare equal.
> 
> I think this problem would not arise if Emacs treated all filenames as
> "completely"/"truly (:-))" (no pun intended) absolute. In my opinion,
> and without knowing many details about the interior design of Emacs,
> this would probably also be the ideal situation.

Maybe, but it won't happen, even if it is better (which I'm not sure
it is).  Too many higher levels expect "~/foo" to keep is
HOME-relative form in Emacs.

Sorry, it's too late to change this.

> In your opinion, what is the reason of why we can not change such names?

Because it works, and doesn't cause any problems, and because by now
there are gobs of Lisp code that assumes this to be true.

> Is this because (1) we do not have enough resources to change such
> discrepancies in nomenclature, or (2) because we are not willing to
> change nomenclature, or (3) we must ensure backwards compatibility?

(3) mostly, but also: this is done for a reason.  Users are happier to
see ~/foo in their file names and prompts than /home/whatever/foo.
Emacs uses these abbreviated file names for that reason.

> (I just grepped for "truename" in the Emacs repository and got 942 hits).
> 
> Independently of what we can change or not, I think it is important to
> reduce discrepancies in nomenclature. Thanks for hearing me out!

Sure, so how about suggesting to the glibc developers that glibc
renames the corresponding APIs to use "true" instead of "real"?

Message #23 received at 77666 <at> debbugs.gnu.org (full text, mbox):

From: Dominik Schrempf <dominik.schrempf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77666 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#77666: Question/discussion about `trusted-content'
Date: Thu, 10 Apr 2025 12:31:59 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>
>> In your opinion, what is the reason of why we can not change such names?
>
> Because it works, and doesn't cause any problems, and because by now
> there are gobs of Lisp code that assumes this to be true.

Well, it caused problems to some of us at least.

>
>> Is this because (1) we do not have enough resources to change such
>> discrepancies in nomenclature, or (2) because we are not willing to
>> change nomenclature, or (3) we must ensure backwards compatibility?
>
> (3) mostly, but also: this is done for a reason.  Users are happier to
> see ~/foo in their file names and prompts than /home/whatever/foo.
> Emacs uses these abbreviated file names for that reason.
>
>> (I just grepped for "truename" in the Emacs repository and got 942 hits).
>>
>> Independently of what we can change or not, I think it is important to
>> reduce discrepancies in nomenclature. Thanks for hearing me out!
>
> Sure, so how about suggesting to the glibc developers that glibc
> renames the corresponding APIs to use "true" instead of "real"?

Haha, I think you'd have to do that, because I am favoring "real"!

Thanks again for the discussion!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.