[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Safe evaluation of macros (was: bug#77341: [PATCH] ; (find-function-
From: |
Eli Zaretskii |
Subject: |
Re: Safe evaluation of macros (was: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros.) |
Date: |
Sat, 05 Apr 2025 11:24:07 +0300 |
> From: Daniel Colascione <dancol@dancol.org>
> Cc: Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
> Date: Fri, 04 Apr 2025 23:52:47 -0700
>
> > What problem exactly are you suggesting to solve? I'm a bit confused :|
> > The patch I submitted for comments simply applies the safety measure we
> > already have for expanding macros: doing so only in trusted code. You
> > seem to suggest that we should employ some solution that is specific to
> > find-function's use case of finding definitions hidden within macros.
> > But this is just one (niche) use case of macro-expansion, so I don't see
> > why it should get special treatment. A general solution for safely
> > expanding macros in untrusted code, however, would make a lot of sense.
>
> So in the meantime we're going to scatter ad-hoc checks of
> "trusted"-ness all over the codebase? That'll cause bugs and breakages
> for years to come and cause people to just mark everything as safe,
> which I'm about to do right now.
>
> It's absurd that I can M-x eval-buffer something then not find a
> definition I trust evaluated because the buffer from which I willingly
> ran code magically became malicious in the several seconds since I
> evaluated it.
Do we have a good idea of what part(s) of macro evaluation could be
unsafe? If so, perhaps we could implement these safety checks where
those potentially unsafe parts of macro evaluation happen?
As for the surprise factor due to silently ignoring some of the
evaluated stuff: maybe we should instead ask the user whether or not
to evaluate?
As for "willingly running code": there's actually more here than quite
literally meets the eye, since some Emacs display features could be
(ab)used to make you think you evaluate something whereas you are
actually evaluating something entirely different, for example in code
snippets received via email messages that use features which preserve
text properties. We should probably try to detect and flag that as
well, either in the low-level code of 'read' or maybe in some
subroutines of eval-last-sexp and its ilk.
Last, but not least: we should enhance the way we set the value of
trusted-content, because what we have now is too rudimentary. For
example, on MS-Windows each file downloaded from the Internet by a Web
browser or saved by a MUA from an email attachment has the fact that
it came from the net recorded in the filesystem, and MS Office
programs then open such files in special restricted mode. (Emacs
could do that as well on MS-Windows, it is quite easy and doesn't even
require changes on the C level.) AFAIU, there's no comparable feature
on Posix systems, but at least EWW and the Emacs MUAs could implement
it in our own code. And then we could use these indications to set
trusted-content more accurately and reliably than we do now.
Bottom line: I think there's a lot to be done here on the
infrastructure levels, before our handling of these aspects could be
considered anywhere near satisfactory. If you have MS Office
installed, open the "Trust Center" of MS Word and review the various
settings they have there. When I do this, I'm truly ashamed when I
compare that with what we have.
Volunteers are more than welcome to work on these important features.
- Re: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros., Daniel Colascione, 2025/04/05
- Re: Safe evaluation of macros (was: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros.),
Eli Zaretskii <=
- Re: Safe evaluation of macros, Eshel Yaron, 2025/04/05
- Re: Safe evaluation of macros, Eli Zaretskii, 2025/04/05
- Re: Safe evaluation of macros, Eshel Yaron, 2025/04/07
- Re: Safe evaluation of macros, Eli Zaretskii, 2025/04/07
- Re: Safe evaluation of macros, Stefan Monnier, 2025/04/07
- Re: Safe evaluation of macros, Eli Zaretskii, 2025/04/07
- Re: Safe evaluation of macros, Philip Kaludercic, 2025/04/07
- Re: Safe evaluation of macros, Daniel Colascione, 2025/04/07
- Re: Safe evaluation of macros, Stefan Monnier, 2025/04/07
- Re: Safe evaluation of macros, Daniel Colascione, 2025/04/07