bug#77666: Question/discussion about `trusted-content'

[Eli Zaretskii]

> From: Dominik Schrempf <dominik.schrempf@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.