This sounds very amateurish from Plasmas part as allowing themes to run bash scripts sounds like a very bad idea no matter how you look at it.
Themes should probably have something like their own domain specific language (DSL) that can be fed to the “theme engine”(?) which will make the requested changes. If additional functionality is needed it should be provided through separate modules/plugins or something.
My thoughts were sandboxing, so run it in a container with only predefined hooks out. That way you know what parts of the system a theme is wanting to change or access (think flatpak).
I do like the use of subset languages to reduce attack surfaces (eBPF comes to mind as an example definitely not a solution to here those lol).
This sounds very amateurish from Plasmas part as allowing themes to run bash scripts sounds like a very bad idea no matter how you look at it.
Themes should probably have something like their own domain specific language (DSL) that can be fed to the “theme engine”(?) which will make the requested changes. If additional functionality is needed it should be provided through separate modules/plugins or something.
My thoughts were sandboxing, so run it in a container with only predefined hooks out. That way you know what parts of the system a theme is wanting to change or access (think flatpak).
I do like the use of subset languages to reduce attack surfaces (eBPF comes to mind as an example definitely not a solution to here those lol).