I’ll admit I have zero insight and haven’t looked into this, but at first glance, I don’t understand why a desktop environment theme engine is unable to provide enough functionality for theme creators to do their thing without resorting to arbitrary command execution…
I trust KDE devs to address this quickly, but this is a pretty major oversight IMO…
“Global Themes” in Plasma do more than just styling
To developers it’s not a surprise that third party plugins can do this sort of thing. It’s as intended. A global theme can ship custom lockscreens, custom applets, custom settings and all of these can run arbitrary bundled code. You can’t constrain this without limiting functionality.
Naturally this is not what an end user expects when browsing for themes, and the warnings don’t make up for the risks.
I hope devs can find a better way to ship this rich functionality, or at least introduce an automated “canary-release” process to the KDE Store that takes down themes that misbehave.
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).
It’s possible that this deletion was a shell script mistake rather than malice, but it really shouldn’t be allowed either way. It’s made even worse by the UI that encourages users to install themes that that could have been made by anyone, with practically no oversight, and with no warning that they can execute arbitrary code.
I like KDE for a lot of reasons, but I’m ashamed of them for this irresponsible blunder.
Let’s hope they respond by closing this hole and any others like it. If they have to break compatibility with existing themes, now seems like a good time for it, since Plasma 6 was only just released.
Uk this prolly is an unpopular opinion, but KDE just isn’t as stable as it should be. When I used KDE (even when my friend used it) something or the other ALWAYS broke. Like just like that! The wifi icon bar or whatever disappeared. Why? Cuz it wanted to… Uggh it just feels like using alpha software, uk…
I’ll admit I have zero insight and haven’t looked into this, but at first glance, I don’t understand why a desktop environment theme engine is unable to provide enough functionality for theme creators to do their thing without resorting to arbitrary command execution…
I trust KDE devs to address this quickly, but this is a pretty major oversight IMO…
“Global Themes” in Plasma do more than just styling
https://blog.davidedmundson.co.uk/blog/kde-store-content/
Naturally this is not what an end user expects when browsing for themes, and the warnings don’t make up for the risks.
I hope devs can find a better way to ship this rich functionality, or at least introduce an automated “canary-release” process to the KDE Store that takes down themes that misbehave.
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).
Original report, in English:
https://old.reddit.com/r/kde/comments/1bixmbx/do_not_install_global_themes_some_wipe_out_all/
It’s possible that this deletion was a shell script mistake rather than malice, but it really shouldn’t be allowed either way. It’s made even worse by the UI that encourages users to install themes that that could have been made by anyone, with practically no oversight, and with no warning that they can execute arbitrary code.
I like KDE for a lot of reasons, but I’m ashamed of them for this irresponsible blunder.
Let’s hope they respond by closing this hole and any others like it. If they have to break compatibility with existing themes, now seems like a good time for it, since Plasma 6 was only just released.
Uk this prolly is an unpopular opinion, but KDE just isn’t as stable as it should be. When I used KDE (even when my friend used it) something or the other ALWAYS broke. Like just like that! The wifi icon bar or whatever disappeared. Why? Cuz it wanted to… Uggh it just feels like using alpha software, uk…