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


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. 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
[–] thurstylark@lemm.ee 59 points 7 months ago (4 children)

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...

[–] eager_eagle@lemmy.world 44 points 7 months ago* (last edited 7 months ago)

"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.

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.

[–] Vipsu@lemmy.world 28 points 7 months ago (1 children)

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.

[–] fruitycoder@sh.itjust.works 2 points 7 months ago

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).

[–] mox@lemmy.sdf.org 18 points 7 months ago

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.

[–] UraniumBlazer@lemm.ee 3 points 7 months ago

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...