bug#44018: Don't consider play-sound-file to be a 'safe' function

[Mattias Engdegård]

15 okt. 2020 kl. 19.26 skrev Eli Zaretskii <eliz@gnu.org>:

> Any details for the uninitiated, or pointers to the info?

You are definitely not uninitiated but others may be so please bear with me.

There are many things that can go wrong:

Playing sound files involves lots of code and libraries, sometimes even 
executing external processes.
Sound file formats are complex and a player typically needs to understand 
several different ones; security-related bugs are not uncommon.
Sound file players may also need access to the hardware, which can greatly 
amplify the severity of any breach.

> Are the risks the same on all the supported platforms, or just on
> some?

The security fundamentals (as above) are the same everywhere; details obviously 
differ. Even if we could pronounce one platform as entirely 'safe' for 
audio-playing, which I don't think is feasible, I don't see the gain from doing 
so.

Obviously 'safe' has to be understood in context. Can Emacs be tricked to call 
play-sound-file with the name of a crafted file as argument? Maybe; as far as I 
can tell, unsafe is only used by SES in Emacs proper, but it seems feasible to 
create a .ses file that calls play-sound-file without asking the user. To 
assume otherwise would be imprudent.

It is true that the hostile Internet has hardened audio file code considerably 
over the years but why would we explicitly make a security exception for a 
function with large attack surface in an application (Emacs) that may very well 
be used for inspection of potentially harmful files?