From: Dmitry Gutov <dmitry@gutov.dev>
To: Eli Zaretskii <eliz@gnu.org>
Cc: jm@pub.pink, stefankangas@gmail.com, 75017@debbugs.gnu.org
Subject: bug#75017: 31.0.50; Untrusted user lisp files
Date: Wed, 25 Dec 2024 01:29:36 +0200 [thread overview]
Message-ID: <4ff33026-e509-41d0-8d02-e67db644a797@gutov.dev> (raw)
In-Reply-To: <865xna60oj.fsf@gnu.org>
On 23/12/2024 14:31, Eli Zaretskii wrote:
>>>> And Emacs will load whatever's written there on the next restart.
>>>> Whether the user wrote to those files, or someone else.
>>> Yes, and your point is..?
>> That whatever malicious code we try to protect against using the
>> "trusted content" mechanism would be executed anyway.
> The scenario I have in mind is this:
>
> . Emacs session is running; when it was started, there was no
> site-init file
> . User notices that site-init file appeared
> . User visits the site-init file
> . Malicious macro in site-init file is executed
>
> IOW, there could be valid situations where the user visits the file
> before restarting Emacs (which would load the file). In these
> situations, it would make sense to treat the file as not trusted --
> unless the user tells us it should always be unconditionally trusted.
>
> IMO, we should only make files and directories trusted by default if
> we are either 100% sure they can never be malicious
Thank you. So the scenario where we would make the distinction is when
the user managed to notice (somehow?) that the file had changed during
the Emacs session, and then went to edit it.
To be frank, I asked the question after reading the scenario from the
first message, and it talks about early-init-file. IIUC this file lives
in the same dir as the plain user-init-file, so the chances of them
being edited by someone other than the user should be about equal, and
we do "trust" the latter file automatically.
Probably not too critical, but inconsistencies can be annoying (the user
has to spend time figuring out whether something is broken and why).
next prev parent reply other threads:[~2024-12-24 23:29 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-21 20:48 bug#75017: 31.0.50; Untrusted user lisp files john muhl
2024-12-22 2:47 ` Stefan Kangas
2024-12-22 3:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-22 6:12 ` Eli Zaretskii
2024-12-22 17:36 ` Stefan Kangas
2024-12-22 18:41 ` Eli Zaretskii
2024-12-22 18:47 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-23 14:10 ` Stefan Kangas
2024-12-23 14:29 ` Eli Zaretskii
2024-12-24 0:35 ` Stefan Kangas
2024-12-24 12:15 ` Eli Zaretskii
2024-12-23 19:15 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-22 6:19 ` Eli Zaretskii
2024-12-22 17:20 ` Stefan Kangas
2024-12-22 18:38 ` Eli Zaretskii
2024-12-22 19:52 ` Dmitry Gutov
2024-12-22 20:23 ` Eli Zaretskii
2024-12-22 20:27 ` Dmitry Gutov
[not found] ` <865xna60oj.fsf@gnu.org>
2024-12-23 14:36 ` Stefan Kangas
2024-12-24 23:29 ` Dmitry Gutov [this message]
2024-12-27 7:39 ` Sean Whitton
2024-12-27 8:35 ` Eli Zaretskii
2024-12-27 13:36 ` Sean Whitton
2024-12-28 12:30 ` Eli Zaretskii
2024-12-28 14:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-29 19:13 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-29 19:13 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-29 19:13 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-29 19:13 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-29 19:14 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-29 19:14 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-29 19:14 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-29 19:14 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-31 4:43 ` Richard Stallman
2024-12-23 0:32 ` john muhl
[not found] ` <86v7va4kj6.fsf@gnu.org>
2024-12-23 17:53 ` john muhl
2024-12-24 5:48 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-24 23:58 ` Stefan Kangas
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ff33026-e509-41d0-8d02-e67db644a797@gutov.dev \
--to=dmitry@gutov.dev \
--cc=75017@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=jm@pub.pink \
--cc=stefankangas@gmail.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).