From: Richard Stallman <rms@gnu.org>
To: Daniel Radetsky <dradetsky@gmail.com>
Cc: bugs@gnu.support, steven@stebalien.com,
christopher@librehacker.com, emacs-devel@gnu.org
Subject: Re: Emacs Arbitrary Code Execution and How to Avoid It
Date: Wed, 11 Dec 2024 23:48:19 -0500 [thread overview]
Message-ID: <E1tLb7b-0007IN-Ud@fencepost.gnu.org> (raw)
In-Reply-To: <hieyeh2wog3c3lp5inmjj3f7xihvumazxbr4xlourwhixuvsae@56ertl6mprml> (message from Daniel Radetsky on Tue, 10 Dec 2024 10:03:52 -0800)
[[[ 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. ]]]
> As I understand it, the issue is that the user has already
> said "execute elisp code in any elisp-mode files,"
Does the user literallky say that. or does the user say something
different which you _interpret_ as _tentamount_ to saying that?
It makes a big difference here.
> If the user has already asked emacs to execute elisp, the
> only thing that could IMO count as a fix is to _prevent_
> them from doing this.
Preventng this is the sort of fix I have in mind. But I have not yet
come across a message explaining precisely what user actions activate
that behavior. Until I learn that, I won't fully understand the
issue. I asked for that info, and I hope I soon come across a
response.
But it looks like this conequence came as a surprse. So I think we
did not anticipate, when adding the feture, that it would have this
effect. We did not intentinally add the feature as a way for users to
say, "Go ahead and randomly execute Elisp code from any of my visited
files."
If we actually want to offer a command by which the user says to
execute unpredictably parts of whatever Elisp files get visited, Emacs
should warn per that "this is dangerous" and ask per to confirm with
`yes'. We should not let users risk stumbling into this mode without
knowing what care they will have to take in this mode.
But even wth understanding, it would be unwise to accept. Everyone
who uses Emacs and looks at Emacs Lisp code will occasionally visit a
file of Elisp code which is _not_ part of per own work. So even if
perse wants this feature for all of a certain project, perse could
fall into a trap by enabling it for _all_ Elisp files that are
visited.
THis leads me to think of settig up a more selective interface
whereby you would enable this for source files of a specific project.
Maybe that would give enough control that it could be safe and yet
still convenient.
--
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)
next prev parent reply other threads:[~2024-12-12 4:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 17:53 Emacs Arbitrary Code Execution and How to Avoid It Christopher Howard
2024-12-03 19:20 ` Gerd Möllmann
2024-12-03 20:25 ` Eshel Yaron
2024-12-08 5:10 ` Richard Stallman
2024-12-06 4:47 ` Richard Stallman
2024-12-06 8:30 ` Eli Zaretskii
2024-12-09 4:57 ` Richard Stallman
2024-12-09 13:59 ` Eli Zaretskii
2024-12-04 9:39 ` Jean Louis
2024-12-04 15:04 ` Steven Allen
2024-12-04 17:02 ` Jean Louis
2024-12-04 17:23 ` Christopher Howard
2024-12-07 4:23 ` Richard Stallman
2024-12-10 18:03 ` Daniel Radetsky
2024-12-11 8:35 ` Eshel Yaron
2024-12-11 9:25 ` Jean Louis
2024-12-11 9:37 ` Daniel Radetsky
2024-12-11 10:38 ` Jean Louis
2024-12-11 10:42 ` tomas
2024-12-11 12:50 ` Daniel Radetsky
2024-12-11 13:10 ` tomas
2024-12-12 4:48 ` Richard Stallman [this message]
2024-12-12 7:39 ` Jean Louis
2024-12-06 4:47 ` Richard Stallman
2024-12-06 5:30 ` Jim Porter
2024-12-06 8:32 ` Eli Zaretskii
2024-12-06 8:29 ` Eli Zaretskii
2024-12-06 16:51 ` Philip Kaludercic
2024-12-08 5:15 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1tLb7b-0007IN-Ud@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=bugs@gnu.support \
--cc=christopher@librehacker.com \
--cc=dradetsky@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=steven@stebalien.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.