Please rename trusted-content to trusted-contents

Please rename trusted-content to trusted-contents

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

"Contents" and "content" are two different words, and for this
meaning, "contents" is correct.  It means the contents of the
file, and that's what we refer to here.

Please let's rename that symbol now before it gets into a release.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Please rename trusted-content to trusted-contents

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 20 Dec 2024 00:23:32 -0500
> 
> "Contents" and "content" are two different words, and for this
> meaning, "contents" is correct.  It means the contents of the
> file, and that's what we refer to here.
> 
> Please let's rename that symbol now before it gets into a release.

The Emacs 30.0.93 pretest was already uploaded with "trusted-content"
in it.  So if we rename it now, we will need to support both
spellings, via defvaralias.  I'm not sure the problem is acute enough
to justify such last-minute changes.

Re: Please rename trusted-content to trusted-contents

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Fri, 20 Dec 2024 00:23:32 -0500
>>
>> "Contents" and "content" are two different words, and for this
>> meaning, "contents" is correct.  It means the contents of the
>> file, and that's what we refer to here.
>>
>> Please let's rename that symbol now before it gets into a release.
>
> The Emacs 30.0.93 pretest was already uploaded with "trusted-content"
> in it.  So if we rename it now, we will need to support both
> spellings, via defvaralias.  I'm not sure the problem is acute enough
> to justify such last-minute changes.

Do we really maintain backwards-compatibility with all pretest releases
also?  I usually consider them more like development branches: used for
testing, not for production.

In any case, I think using the right word is better, so if we need a
defvaralias then so be it, IMO.  I don't see how it could hurt, and we
could even define-obsolete-variable-alias.

Re: Please rename trusted-content to trusted-contents

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 20 Dec 2024 04:42:31 -0500
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Richard Stallman <rms@gnu.org>
> >> Date: Fri, 20 Dec 2024 00:23:32 -0500
> >>
> >> "Contents" and "content" are two different words, and for this
> >> meaning, "contents" is correct.  It means the contents of the
> >> file, and that's what we refer to here.
> >>
> >> Please let's rename that symbol now before it gets into a release.
> >
> > The Emacs 30.0.93 pretest was already uploaded with "trusted-content"
> > in it.  So if we rename it now, we will need to support both
> > spellings, via defvaralias.  I'm not sure the problem is acute enough
> > to justify such last-minute changes.
> 
> Do we really maintain backwards-compatibility with all pretest releases
> also?  I usually consider them more like development branches: used for
> testing, not for production.

We don't usually maintain compatibility in those cases, but this
situation is special: we are very close to the release, and I don't
want to waste one more pretest because we renamed the variable.

> In any case, I think using the right word is better, so if we need a
> defvaralias then so be it, IMO.  I don't see how it could hurt, and we
> could even define-obsolete-variable-alias.

From where I stand, if we decide to rename it, we must have a
defvaralias for the other name.

And FWIW, renaming doesn't sound very important to me: Emacs is full
of mis-spellings and English usage that is not 110% correct, so I
don't see this as a catastrophe.  After all, Stefan's English is
either his first language or close, so if he is okay with that name,
we are not in a bad place.

Re: Please rename trusted-content to trusted-contents

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Fri, 20 Dec 2024 04:42:31 -0500
>> Cc: emacs-devel@gnu.org
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Richard Stallman <rms@gnu.org>
>> >> Date: Fri, 20 Dec 2024 00:23:32 -0500
>> >>
>> >> "Contents" and "content" are two different words, and for this
>> >> meaning, "contents" is correct.  It means the contents of the
>> >> file, and that's what we refer to here.
>> >>
>> >> Please let's rename that symbol now before it gets into a release.
>> >
>> > The Emacs 30.0.93 pretest was already uploaded with "trusted-content"
>> > in it.  So if we rename it now, we will need to support both
>> > spellings, via defvaralias.  I'm not sure the problem is acute enough
>> > to justify such last-minute changes.
>>
>> Do we really maintain backwards-compatibility with all pretest releases
>> also?  I usually consider them more like development branches: used for
>> testing, not for production.
>
> We don't usually maintain compatibility in those cases, but this
> situation is special: we are very close to the release, and I don't
> want to waste one more pretest because we renamed the variable.
>
>> In any case, I think using the right word is better, so if we need a
>> defvaralias then so be it, IMO.  I don't see how it could hurt, and we
>> could even define-obsolete-variable-alias.
>
> From where I stand, if we decide to rename it, we must have a
> defvaralias for the other name.
>
> And FWIW, renaming doesn't sound very important to me: Emacs is full
> of mis-spellings and English usage that is not 110% correct, so I
> don't see this as a catastrophe.  After all, Stefan's English is
> either his first language or close, so if he is okay with that name,
> we are not in a bad place.

I'm copying in Stefan Monnier, in case he has any comments.

Re: Please rename trusted-content to trusted-contents

[Stefan Monnier]

>> don't see this as a catastrophe.  After all, Stefan's English is
>> either his first language or close,

English is my third language.  I use it professionally and have lived in
the US for many years, so it's not too terrible (*much* better than my
second language), but it's pretty far from perfect.

>> so if he is okay with that name, we are not in a bad place.
> I'm copying in Stefan Monnier, in case he has any comments.

Indeed, I hesitated between `trusted-content` and `trusted-contents` but
not long enough to learn which is right.

I'll rename it ASAP, thanks Richard!


        Stefan

Re: Please rename trusted-content to trusted-contents

[Stefan Monnier]

>>> so if he is okay with that name, we are not in a bad place.
>> I'm copying in Stefan Monnier, in case he has any comments.
> Indeed, I hesitated between `trusted-content` and `trusted-contents` but
> not long enough to learn which is right.

OK, I tried to figure it out, but at least the info I found wasn't
very definitive.  It seems to have to do with whether it's countable or
not, or whether it describe the "conceptual ideas" contained as opposed
to the actual elements contained.
I'm not sure which is more appropriate in this case and even less sure
that one of the two is wrong.

A related question is what to do with `untrusted-content` (which is the
identifier with which I aligned mine).  If we rename `trusted-content`,
we should likely rename `untrusted-content` as well (and this one
would require a backward compatibility alias).

> I'll rename it ASAP, thanks Richard!

Here's the patch I came up with via `grep` (without renaming
`untrusted-content`).


        Stefan


diff --git a/doc/emacs/misc.texi b/doc/emacs/misc.texi
index 97a82747bfc..e0ce2233cfe 100644
--- a/doc/emacs/misc.texi
+++ b/doc/emacs/misc.texi
@@ -298,9 +298,9 @@ Host Security
 Flymake, completion, and some other features, unless the visited file is
 @dfn{trusted}.  It is up to you to specify which files on your system
 should be trusted, by customizing the user option
-@code{trusted-content}.
+@code{trusted-contents}.
 
-@defopt trusted-content
+@defopt trusted-contents
 The value of this option is @code{nil} by default, which means no file
 is trusted.  You can customize the variable to be a list of one or more
 names of trusted files and directories.  A file name that ends in a
diff --git a/etc/NEWS b/etc/NEWS
index 61cb66387bb..5ce4c3cd7f8 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -200,7 +200,7 @@ see the variable 'url-request-extra-headers'.
 * Changes in Emacs 30.1
 
 +++
-** New user option 'trusted-content' to allow potentially dangerous features.
+** New user option 'trusted-contents' to allow potentially dangerous features.
 This variable lists those files and directories whose content Emacs should
 consider as sufficiently trusted to run any part of the code contained
 therein even without any explicit user request.
@@ -1871,7 +1871,7 @@ In the past they included a terminating newline in most cases but not all.
 +++
 *** 'elisp-flymake-byte-compile' is disabled for untrusted files.
 For security reasons, this backend can be used only in those files
-specified as trusted according to 'trusted-content' and emits an
+specified as trusted according to 'trusted-contents' and emits an
 "untrusted content" warning otherwise.
 This fixes CVE-2024-53920.
 
diff --git a/lisp/files.el b/lisp/files.el
index 86eff296459..62905da1ee5 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -714,7 +714,7 @@ untrusted-content
 This variable might be subject to change without notice.")
 (put 'untrusted-content 'permanent-local t)
 
-(defcustom trusted-content nil
+(defcustom trusted-contents nil
   "List of files and directories whose content we trust.
 Be extra careful here since trusting means that Emacs might execute the
 code contained within those files and directories without an explicit
@@ -732,21 +732,21 @@ trusted-content
   :type '(choice (repeat :tag "List" file)
                  (const :tag "Trust everything (DANGEROUS!)" :all))
   :version "30.1")
-(put 'trusted-content 'risky-local-variable t)
+(put 'trusted-contents 'risky-local-variable t)
 
-(defun trusted-content-p ()
+(defun trusted-contents-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'."
+See also `trusted-contents'."
   ;; 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.
   (and (not untrusted-content)
        (or
-        (eq trusted-content :all)
+        (eq trusted-contents :all)
         (and
          buffer-file-truename
-         (with-demoted-errors "trusted-content-p: %S"
+         (with-demoted-errors "trusted-contents-p: %S"
            (let ((exists (file-exists-p buffer-file-truename)))
              (or
               ;; We can't avoid trusting the user's init file.
@@ -755,7 +755,7 @@ trusted-content-p
                 (equal buffer-file-truename user-init-file))
               (let ((file (abbreviate-file-name buffer-file-truename))
                     (trusted nil))
-                (dolist (tf trusted-content)
+                (dolist (tf trusted-contents)
                   (when (or (if exists (file-equal-p tf file) (equal tf file))
                             ;; We don't use `file-in-directory-p' here, because
                             ;; we want to err on the conservative side: "guilty
diff --git a/lisp/ielm.el b/lisp/ielm.el
index 7511d4b02ae..da5ad992389 100644
--- a/lisp/ielm.el
+++ b/lisp/ielm.el
@@ -580,7 +580,7 @@ inferior-emacs-lisp-mode
        ielm-fontify-input-enable
        (comint-fontify-input-mode))
 
-  (setq-local trusted-content :all)
+  (setq-local trusted-contents :all)
   (setq comint-prompt-regexp (concat "^" (regexp-quote ielm-prompt)))
   (setq-local paragraph-separate "\\'")
   (setq-local paragraph-start comint-prompt-regexp)
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 17606352c4a..c48861712de 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -451,7 +451,7 @@ elisp--local-macroenv
 (defvar elisp--macroexpand-untrusted-warning t)
 
 (defun elisp--safe-macroexpand-all (sexp)
-  (if (not (trusted-content-p))
+  (if (not (trusted-contents-p))
       ;; FIXME: We should try and do better here, either using a notion
       ;; of "safe" macros, or with `bwrap', or ...
       (progn
@@ -1338,7 +1338,7 @@ lisp-interaction-mode
 \\{lisp-interaction-mode-map}"
   :abbrev-table nil
   (setq-local lexical-binding t)
-  (setq-local trusted-content :all))
+  (setq-local trusted-contents :all))
 
 ;;; Emacs Lisp Byte-Code mode
 
@@ -2203,7 +2203,7 @@ elisp-flymake-byte-compile
   "A Flymake backend for elisp byte compilation.
 Spawn an Emacs process that byte-compiles a file representing the
 current buffer state and calls REPORT-FN when done."
-  (unless (trusted-content-p)
+  (unless (trusted-contents-p)
     ;; FIXME: Use `bwrap' and friends to compile untrusted content.
     ;; FIXME: We emit a message *and* signal an error, because by default
     ;; Flymake doesn't display the warning it puts into "*flmake log*".
diff --git a/lisp/simple.el b/lisp/simple.el
index 088678ba857..fd027ec1915 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2033,7 +2033,7 @@ read--expression
         (set-syntax-table emacs-lisp-mode-syntax-table)
         (add-hook 'completion-at-point-functions
                   #'elisp-completion-at-point nil t)
-        (setq-local trusted-content :all)
+        (setq-local trusted-contents :all)
         (run-hooks 'eval-expression-minibuffer-setup-hook))
     (read-from-minibuffer prompt initial-contents
                           read--expression-map t

Re: Please rename trusted-content to trusted-contents

[Morgan Willcock]

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

>>>> so if he is okay with that name, we are not in a bad place.
>>> I'm copying in Stefan Monnier, in case he has any comments.
>> Indeed, I hesitated between `trusted-content` and `trusted-contents` but
>> not long enough to learn which is right.
>
> OK, I tried to figure it out, but at least the info I found wasn't
> very definitive.  It seems to have to do with whether it's countable or
> not, or whether it describe the "conceptual ideas" contained as opposed
> to the actual elements contained.
> I'm not sure which is more appropriate in this case and even less sure
> that one of the two is wrong.
>
> A related question is what to do with `untrusted-content` (which is the
> identifier with which I aligned mine).  If we rename `trusted-content`,
> we should likely rename `untrusted-content` as well (and this one
> would require a backward compatibility alias).

Isn't it the file path that is being configured and trusted rather than
the file content(s)?  I would have expected something like trusted-paths
and untrusted-paths.

I only speak English, but "content(s)" seems more confusing to me
because another file with the same content(s) isn't necessarily going to
be treated in the same way.

I think similar features in other software will only refer to the
settings as locations to trust.  Here are two examples:
https://code.visualstudio.com/docs/editor/workspace-trust
https://support.microsoft.com/en-us/office/add-remove-or-change-a-trusted-location-in-microsoft-office-7ee1cdc2-483e-4cbb-bcb3-4e7c67147fb4

-- 
Morgan Willcock

RE: [External] : Re: Please rename trusted-content to trusted-contents

[Drew Adams]

> OK, I tried to figure it out, but at least the info I found wasn't
> very definitive.  It seems to have to do with whether it's countable or
> not, or whether it describe the "conceptual ideas" contained as opposed
> to the actual elements contained.

Right.  And the distinction isn't very important in
practice, as the two are often used interchangeably
(arguably incorrectly, but ... usage wins in the end,
and who knows what verdict/measure the future will hold).

Googling is helpful.  This bit from one search hit
isn't a bad overview:

 Thus, while a book has contents (sections, chapters,
 subchapters, etc.), the content of a book is the story
 it tells.

 * This is a brief summary of the contents of the book.

 * The title says one thing, but the content of the book
   is completely different.

https://www.pristineword.com/noun-content-contents/

"Content" is the meaning that's "contained", abstractly,
in something.  Something's "contents" are the actual
things contained in it - the something is regarded only
as a container.

You might (sort of) think of this in terms of type
versus constituent/instance.  "Content" looks beyond
the contained individuals to what they have in common,
and thus to what they represent/mean collectively.

 * The contents of that directory are image files.
   It contains files.

 * The content of that directory is images (file type:
   image).  That's the directory's purpose/meaning o.

Re: [External] : Re: Please rename trusted-content to trusted-contents

[Björn Bidar]

Drew Adams <drew.adams@oracle.com> writes:

>> OK, I tried to figure it out, but at least the info I found wasn't
>> very definitive.  It seems to have to do with whether it's countable or
>> not, or whether it describe the "conceptual ideas" contained as opposed
>> to the actual elements contained.
>
> Right.  And the distinction isn't very important in
> practice, as the two are often used interchangeably
> (arguably incorrectly, but ... usage wins in the end,
> and who knows what verdict/measure the future will hold).
>
> Googling is helpful.  This bit from one search hit
> isn't a bad overview:
>
>  Thus, while a book has contents (sections, chapters,
>  subchapters, etc.), the content of a book is the story
>  it tells.
>
>  * This is a brief summary of the contents of the book.
>
>  * The title says one thing, but the content of the book
>    is completely different.
>
> https://www.pristineword.com/noun-content-contents/
>
> "Content" is the meaning that's "contained", abstractly,
> in something.  Something's "contents" are the actual
> things contained in it - the something is regarded only
> as a container.

I was thinking the same. Contents is wrong to me in this context.
as _the content_ by itself is already a multiple of something.

It is like writing peoples for multiple person when people
is already a multiple. Peoples similar the contents refers to
the persons inside people e.g. American Peoples Party.

But English in IMHO quite confusing when it comes to the s suffix and
not.
I can relate very much.

I regret not using a grammar checker sometimes..

> You might (sort of) think of this in terms of type
> versus constituent/instance.  "Content" looks beyond
> the contained individuals to what they have in common,
> and thus to what they represent/mean collectively.
>
>  * The contents of that directory are image files.
>    It contains files.
>
>  * The content of that directory is images (file type:
>    image).  That's the directory's purpose/meaning o.

Re: Please rename trusted-content to trusted-contents

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I'll rename it ASAP, thanks Richard!

  > Here's the patch I came up with via `grep` (without renaming
  > `untrusted-content`).

Thanks.

I think `untrusted-content' should be renamed too, for the same
reasons.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Please rename trusted-content to trusted-contents

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Do we really maintain backwards-compatibility with all pretest releases
  > also?  I usually consider them more like development branches: used for
  > testing, not for production.

I agree.  We can always suggest "Please upgrade to the actual release."

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)