this post was submitted on 22 Mar 2024
190 points (93.6% liked)
Technology
59295 readers
4310 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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...