--- Begin Message ---
|
Subject: |
Don't consider play-sound-file to be a 'safe' function |
|
Date: |
Thu, 15 Oct 2020 18:55:26 +0200 |
We should remove play-sound-file from the list of 'safe' functions in
unsafep.el.
The risks outweigh the benefits here; this is just basic security engineering.
The attack surface of play-sound-file is considerable.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#44018: Don't consider play-sound-file to be a 'safe' function |
|
Date: |
Sat, 31 Oct 2020 14:33:02 +0100 |
31 okt. 2020 kl. 09.06 skrev Eli Zaretskii <eliz@gnu.org>:
> I'm okay with doing this, but please add commentary that explains
> these removals and the general policy for considering a function
> "safe".
Agreed -- done and pushed.
I also removed 'throw' since it can be used to alter the flow control of a
program if evaluated inside a 'catch' form as well as inject an arbitrary value
that way, and 'catch' since it makes little sense without 'throw'.
More importantly, 'replace-regexp-in-string' was removed because it could be
used to execute arbitrary code.
I've removed the side-effect-free property of 'assoc' for the same reason.
These mistakes, and the fact that unsafep allows some limited use of setq,
apply, let, push, pop etc, makes me doubt the safety of unsafep entirely and
would recommend against using it in new code. The attack surface is simply too
large and difficult to overview. For example, the long list of
'side-effect-free' functions hasn't really been vetted with security in mind
(assoc is a case in point).
--- End Message ---