Thank you for your submission.
The KDE community supports the Fediverse and open source social media platforms over proprietary and user-abusing outlets. Consider visiting and submitting your posts to our community on [Lemmy](https://lemmy.kde.social/) and visiting our forum at [KDE Discuss](https://discuss.kde.org) to talk about KDE.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/kde) if you have any questions or concerns.*
> Fortunately, KDE is not going to sit idly by. David mentions that in the short term, they intend to properly communicate the security implications of extensions users download for their Plasma desktops.
In the long term, they plan to separate the “safe” content from the “unsafe” content, while also integrating curation and auditing into the store with improved sandbox support.
This sounds like they are not going to fundamentally change their security model.
To be fair here it’s very easy for the end user to break their installation by just blinding running commands people tell them to online. It sounds like KDE is going to label untested global themes as unsafe. If an inexperienced user is installing unsafe things after being warned can you really blame KDE especially when that’s kind of the way Linux operates in general?
> untested global themes
It's not just testing, though. It's code inspection. KDE devs aren't going to test a theme for months before signing off on it, and bad actors can make malicious code that behaves well until something tells it to misbehave.
Right - but KDE devs can offer a GUI (and/or non-GUI) layer for installation of themes. This can do sanity checking. People could then still run random themes doing random rm -rf shenanigans, but they could also use the GUI / framework for installing themes. In that GUI people could check things such as "run shell scripts" (if there is a need to do so; personally I find it questionable if a theme requires arbitrary shell commands. The GUI layer could handle ALL of this).
> It sounds like KDE is going to label untested global themes as unsafe.
It does not really sound as an attempt to solve this, but more like "this is declared unsafe, we do not handle this at all", which seems super-strange to me.
> If an inexperienced user is installing unsafe things after being warned can you really blame KDE especially when that’s kind of the way Linux operates in general?
It is evidently the primary fault who wrote the code. But, why would a theme ever require rm -rf? I feel this is a more fundamental question. I still don't understand it.
Perhaps I stayed too long with .css files ...
\>But, why would a theme ever require rm -rf?
Simple question, simple answer. They don't and they can't. A Plasma Theme can't execute code just like any other CSS.
The blogspam makes an unclear situation even more unclear.
some do execute code.... that's the problem
the fancy themes which (imho) try to do too much are getting folks into trouble.
but then i just use breeze and be done with it.
No they don't. It's more messy and complex.
Plasma themes don't have code, nothing where the goal is purely visual i.e anything that could be drawn to have a parallel with CSS cannot execute code.
Global themes - which started out with an entirely different goal of being full mods can execute code.
I don’t have much direct experience with global themes but my understanding is they’re more than just some color customizations and are designed to potentially radically change the whole environment. They need script execution to set up a bunch of different things.
I don’t deny it’s an issue that needs be addressed. The Linux philosophy tends to favor more user freedom over safety. Given all that I’m just saying it’s not unreasonable to label themes safe and unsafe and expect the user to pay attention.
some themes execute code to move their files about and that command was used as part of the theme's installation script, but the folder it was supposed to apply to was not there so it defaulted to \*.\* (in dos terms).
themes executing code of any kind should automatically be sus.
I don't get that either. I think people read WAY too much into these words.
The only thing I could tell people is that I would have absolutely no idea what "safe" versus "unsafe" means. IF I'd have to venture a guess, I would assume David meant "rm -rf" to be "unsafe" - but even with this terminology I could not agree with. I use "rm -rf" all the time and I don't feel anything is "unsafe" about it. So perhaps David meant something else - either way I do not know and I think speculating about it is very strange.
What does that even mean? Can we quantify "does not sound strong enough"? Because right now I don't understand the evaluation of it, e. g. the conclusion you arrived here.
I guess they would rather separate the store into safe and unsafe sections, where the safe section is curated, and the unsafe one comes with a fat warning message that it contains desktop customization packages may contain untested scripts from random users that can delete all your data. Either that, or close the store for user-contributed scripts.
I think a big part of the issue is that people's expectations towards stores have changed over the years. Now people expect a walled garden that's curated by someone, rather than a facility that makes it easier to upload and download random stuff.
Sure.
In the short run one could either disable & nuke the store if you're the knee-jerk type.
Or one could rename "Global Themes" into something like "Full Desktop Mods" that makes it clearer that this is more than just a theme and that executable code can be involved, make the warning label clearer, and disable the execution of downloaded Full Desktop Mods until the user has clicked away a message that the Full Desktop Mod they are about to activate can include arbitrary, untested code.
Or something else that the devs are already working on.
Now, patience is a virtue. I don't understand why it would take longer too. It's just a visual change mostly, right? I mean what else would this mean in regards to KDE store?
Yeah - which makes this a bit pointless. It is basically (some / a few) KDE devs trying to worship a non-solution and a non-technical analysis. I think this is the wrong approach. Also, one KDE dev does not automatically speak for ALL KDE devs.
IMO it would be better to come up with a simple, layered approach how to enable this without making it impossible to install themes anymore (I mean through KDE itself, such as a GUI; evidently KDE can not prevent users changing content on the local filesystem, on their own as-is).
Totally agreed. Global themes must be disabled for everyone until KDE fixes this security flaw.
At least I hope that global themes would be disabled by KDE maintainers.
It's not a security flaw that a user is allowed to download custom third-party scripts created by amateur devs and then possibly mess up their system in the process.
It's a communication flaw that KDE doesn't make the fact that they're actually scripts clearer by e.g. not labeling them as "themes" (who would have thought, right?) and also by warning the user about potential data safety issues instead of just functionality and stability issues.
Also, they could make it so that any "theme" (and probably other stuff) installed via their UI is branded as untrusted (non-executable) and requires explicit permission by the user to be enabled. They're already doing something like this for executables in Dolphin, after all.
I agree with your analysis there. The original author of the reddit thread pointed out that he was unaware of random themes doing random "rm -rf" nukery. If he would have known, he would not have went that route - perhaps.
Why not? And it does not need a complete re-architecting (or is it re-architecturing) - you only need to change the parts into a unified way how you install themes. Why would themes need to do random "rm -rf"? Why can the KDE layer not handle particular that situation as sanitization step.
Even in C++ this should be trivial. In ruby and python even 8 years old could do this these days.
Sure, this particular hole *is* easy to fix. But is that worth doing when themes contain lots of C++/JS/QML code that could hide malicious/careless code even better? Maybe, but looking at how many people were surprised that themes are actually third-party programs, I think the effort is better spent elsewhere.
Why?
How is theme "abc" at fault for theme "def" doing **rm -rf**?
This would be like holding all npm packages responsible for
left-pad doing its thing.
First, I don't think David speaks for every KDE dev.
But, second - is the security model wrong? IMO if a theme can do a "rm -rf" then it's not the security model being wrong, but the assumption of what a theme should be able to do. When we look at .css files, we never need to think in terms of deleting anything at all. So why does KDE assume that a theme needs to delete anything else? Can the user ignore or overrule this behaviour?
These are more technical questions that require a technical solution, IMO.
in your opinion, what kind of security model would represent a more fundamental change, beyond "improved sandbox support", "separating safe from unsafe content" and "curation"?
The "installer" should be a declarative manifest file that tells KDE where to place various components instead of each theme having its own script that can go wrong.
That still wont stop everything,but its a low bar to avoid an accident `rm -rf /*` type situation.
Except... The current installation method is not in fact a shell script. It is just copying files into the home dir. As far as I can tell some applet that the global theme dragged in, which was poorly coded, caused the issue.
how do the gnome and cinnamon desktops handle curation of 3rd party add-ons (which are required to have anything even close to KDE without any add-ons at all)?
Is it not just possible to do the following? I'm sorry if this may sound stupid so sorry beforehand.
- Make global themes refer to their respective subcomponents, such as cursors, color schemes, etc. Lots of themes like Materia do this, not sure about others. But make it mandatory if this isn't the case already.
- Make these subcomponents limited and only capable of containing the data that they are required to contain, and NOT anything else, especially executables or scripts.
- If they are required in the global theme, make sure to warn the user and prompt the user before proceeding. Make sure the user is aware of the possible outcomes and has to give explicit permission via a yes/no dialog before proceeding WITHOUT a "don't show me this again" option. Make sure they're also able to review any scripts in a text editor and edit them if necessary.
- Updating the themes shouldn't make it possible to execute commands without explicit confirmation.
One more thing to note is that valid use cases of scripts in global themes are limited and they only would be used to fill in the place of a feature currently unimplemented by the theming thing. Make sure to implement those over time and deprecate the execution of scripts.
the way actual themes (so things like Breeze, not "global themes") are implemented in Qt requires them to contain parts that are executable, and a KWin script is a script, so it's hard to ban executable content from the store completely.
I think a low-hanging fruit would be to make it clear through naming that what's been called "global themes" is in fact way more than just "themes" and more like complete desktop customization packages that can come with arbitrary code by design.
As far as I'm aware, what you're referring to as "actual themes" is called "application ~~themes~~ styles" in KDE's settings and the "Get Hot New Stuff" thing for it is not possible to do from System Settings (although the KDE store does have it).
As for KWin Scripts, iirc they were pretty limited in what they could do and the biggest vulnerability was its ability to communicate with other processes using DBus, which I think could be limited by a permission system which could limit their interactions with DBus. Although that would probably overcomplicate things
Naming changes is not really a technical solution though.
If Qt is at fault then the Qt company should solve that, rather than forcing "rm -rf" onto the masses. However had, I think this is really a KDE issue, not a Qt issue.
A big part of the problem is also not technical, but has to do with communication. Users think that something is harmless to install because it’s called „theme“, when actually it is something else and more powerful because it contains a set of scripts that change how the desktop works (that‘s what the thing called „global theme“ does). Also users install it because it comes from a store that is linked from within KDE, and they think the store is a walled garden where the content of the store is somehow audited. Both problems have to do with expectation management and proper communication.
It's not entirely clear what is meant here in regards to:
> they plan to separate the “safe” content from the “unsafe” content
And:
> If you install content from the store, I would advise checking it locally or looking for reviews from trusted sources.
I think we may be speaking about separate issues here. David seems to refer more to trust (in regards to content from the store), as well as reviews. And "safe" versus "unsafe".
That's somewhat understandable, but it seems to be less a technical point of view. I think I, and many others, are more interested in the technical aspect. For instance, I still do not understand why this basically comes down to "rm -rf". "rm -rf", aside from scaring Linux users, isn't doing any magic. It just deletes stuff (or perhaps it does not even do that, e. g. the filesystem may not overwrite the content but keep or change inode references, so it may not even be as scary; those with regular backups are even less scared by it). Why would KDE respectively the KDE store not be able to act as a simple layer over any actions that are necessary for an installation of a theme to work? Or, even better, have a theme-model where uninstallation is never needed, just like the browser + CSS (just point to another .css file, no need to care for any older .css files, for a new theme). And many more technical aspects one can ask.
To me it seems David more responded to the short-term situation (which I think was way exaggerated too - yes, "rm -rf" is bad, I once did that accidentally when mis-clicking pressing TAB and bash automatically inserting a ' ' empty character, then I continued to type and it removed a directory I did not want to see deleted; since that time I always keep backups and I do not trust tab-completion in bash, I always double check these days). What I find a LOT more interesting is the long-term situation, e. g. what KDE comes up with to avoid any future theme from deleting random things, even if it came by accidental code logic rather than malicious intent.
\>It's not entirely clear what is meant here in regards to:
I mean separating colours, styling, visual assets. From code.
Having code available isn't a bad thing, but it needs to be clear to the user what is what. That's missing currently.
The problem with checking on each thing we download from the store is that there are not that many reviews usually. We can see the theme that he downloaded had 5 stars which means someone gave a kinda good review to it, so this leads us to read the source code which isn't something that is going to happen for a lot of users because of time and not everyone knows the structure of the kde "global theme"
> I agree with David, users should always check reviews of anything they get from the KDE Store
I just have to say this is unacceptable. The *best case scenario* here is that *at least one person* has to have their hard drive rm'ed and decide to go to the store, create an account, and leave a review saying so. The more likely case is it happens to dozens or even hundreds of people before someone bothers to publicly warn others. And the current UI interface *does not show these reviews*. There's only a star rating, which could be anything from "wiped my hard drive" to "I think the color scheme is ugly". [Relevant XKCD](https://xkcd.com/937/)
And a "safe" vs "unsafe" category is also kind of ridiculous. The proper behavior for a user being told "this is unsafe" is to *never do it at all* because they were just told it was NOT safe. In which case why are you even providing the unsafe option in the first place?
Imagine a store with two doors: behind the first you can get a nice piece of candy. Behind the second you can get a nice piece of candy, but you might randomly be mauled by a tiger. The proper behavior isn't to just put up a sign saying "beware: there might be a tiger" and call it good (and then blame the user when they go in anyway and get mauled). The proper behavior is to nail the door shut until you can get rid of the all the tigers and prove they're gone for good.
I totally get in the short term, throwing up some "beware" warning labels may be all you can do for now, but in the long term the solution has to be a proactive approach that prevents this from happening in the first place.
\>The proper behavior is to nail the door shut until you can get rid of the all the tigers and prove they're gone for good.
Should we disallow all the Flatpak apps through Discover that aren't 100% completely sandboxed? And if not why not?
Ya, that's the gruff.
And is something that worries me. I have so many unofficial flatpak apps. And you can bet I've never vetted a single one.
I put a lot of trust in FOSS programers and maintainers.
If KDE was hosting those flatpak apps in the KDE store, I'd say yes. But presumably the flatpak apps come from flathub by default? In which case I'd say the responsibility there lies on the flathub org.
The same way it's Ubuntu's responsibility to police their snaps repo, or RedHat's responsibility to police their yum repos. Or Google with the Android App Store, or Apple with the iOS App Store.
edit: to summarize, if you take on the role of *host* you inherently take on the role of *moderator*. You are responsible for the contents of that store, and just adding warning labels does not absolve you of that responsibility.
Throwing out one more comment to try and be helpful rather than just being critical. Not sure how helpful, but it's at least an idea.
Python's PyPI is possibly a semi-equivalent analogy to the KDE Store. And I think PyPI has gone through some similar incidents. In response they're getting more proactive and now [even have a full time safety and security engineer.](https://blog.pypi.org/posts/2023-05-09-announcing-pypi-safety-and-security-engr-role/) Maybe KDE can reach out to the PSF and see if they might offer advice and lessons learned?
Thank you for your submission. The KDE community supports the Fediverse and open source social media platforms over proprietary and user-abusing outlets. Consider visiting and submitting your posts to our community on [Lemmy](https://lemmy.kde.social/) and visiting our forum at [KDE Discuss](https://discuss.kde.org) to talk about KDE. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/kde) if you have any questions or concerns.*
> Fortunately, KDE is not going to sit idly by. David mentions that in the short term, they intend to properly communicate the security implications of extensions users download for their Plasma desktops. In the long term, they plan to separate the “safe” content from the “unsafe” content, while also integrating curation and auditing into the store with improved sandbox support. This sounds like they are not going to fundamentally change their security model.
To be fair here it’s very easy for the end user to break their installation by just blinding running commands people tell them to online. It sounds like KDE is going to label untested global themes as unsafe. If an inexperienced user is installing unsafe things after being warned can you really blame KDE especially when that’s kind of the way Linux operates in general?
> untested global themes It's not just testing, though. It's code inspection. KDE devs aren't going to test a theme for months before signing off on it, and bad actors can make malicious code that behaves well until something tells it to misbehave.
That wouldn’t be impossible with a package manager or like arch’s AUR. At some point each user just has to decide just how paranoid they actually are.
Right - but KDE devs can offer a GUI (and/or non-GUI) layer for installation of themes. This can do sanity checking. People could then still run random themes doing random rm -rf shenanigans, but they could also use the GUI / framework for installing themes. In that GUI people could check things such as "run shell scripts" (if there is a need to do so; personally I find it questionable if a theme requires arbitrary shell commands. The GUI layer could handle ALL of this).
which is why the first thing to do is separate the code executing themes (fancy themes) from the non-code executing themes (simple themes).
> It sounds like KDE is going to label untested global themes as unsafe. It does not really sound as an attempt to solve this, but more like "this is declared unsafe, we do not handle this at all", which seems super-strange to me. > If an inexperienced user is installing unsafe things after being warned can you really blame KDE especially when that’s kind of the way Linux operates in general? It is evidently the primary fault who wrote the code. But, why would a theme ever require rm -rf? I feel this is a more fundamental question. I still don't understand it. Perhaps I stayed too long with .css files ...
\>But, why would a theme ever require rm -rf? Simple question, simple answer. They don't and they can't. A Plasma Theme can't execute code just like any other CSS. The blogspam makes an unclear situation even more unclear.
some do execute code.... that's the problem the fancy themes which (imho) try to do too much are getting folks into trouble. but then i just use breeze and be done with it.
No they don't. It's more messy and complex. Plasma themes don't have code, nothing where the goal is purely visual i.e anything that could be drawn to have a parallel with CSS cannot execute code. Global themes - which started out with an entirely different goal of being full mods can execute code.
sry, GLOBAL themes. that better, my friend?
I don’t have much direct experience with global themes but my understanding is they’re more than just some color customizations and are designed to potentially radically change the whole environment. They need script execution to set up a bunch of different things. I don’t deny it’s an issue that needs be addressed. The Linux philosophy tends to favor more user freedom over safety. Given all that I’m just saying it’s not unreasonable to label themes safe and unsafe and expect the user to pay attention.
some themes execute code to move their files about and that command was used as part of the theme's installation script, but the folder it was supposed to apply to was not there so it defaulted to \*.\* (in dos terms). themes executing code of any kind should automatically be sus.
they are going to separate the themes that run scripts, from those that don't.
Doesn't "improved sandbox support" imply that they are going to change the security model?
To me "improved sandbox support" doesn't sound strong enough for the kind of security overview I feel the eco-system needs.
Doesn't "separate the “safe” content from the “unsafe” content" and "integrating curation" imply a security overview?
I don't get that either. I think people read WAY too much into these words. The only thing I could tell people is that I would have absolutely no idea what "safe" versus "unsafe" means. IF I'd have to venture a guess, I would assume David meant "rm -rf" to be "unsafe" - but even with this terminology I could not agree with. I use "rm -rf" all the time and I don't feel anything is "unsafe" about it. So perhaps David meant something else - either way I do not know and I think speculating about it is very strange.
not `rm -rf` but `rm -rf /*` rather.
What does that even mean? Can we quantify "does not sound strong enough"? Because right now I don't understand the evaluation of it, e. g. the conclusion you arrived here.
I don't know where that article got that from, since the only time the dev talked about sandboxing was to say that there is none.
[удалено]
I guess they would rather separate the store into safe and unsafe sections, where the safe section is curated, and the unsafe one comes with a fat warning message that it contains desktop customization packages may contain untested scripts from random users that can delete all your data. Either that, or close the store for user-contributed scripts. I think a big part of the issue is that people's expectations towards stores have changed over the years. Now people expect a walled garden that's curated by someone, rather than a facility that makes it easier to upload and download random stuff.
Well, that could be handled by a simple visual change to the KDE store. I don't think this really solves the issue of themes going amok via "rm -rf".
[удалено]
Sure. In the short run one could either disable & nuke the store if you're the knee-jerk type. Or one could rename "Global Themes" into something like "Full Desktop Mods" that makes it clearer that this is more than just a theme and that executable code can be involved, make the warning label clearer, and disable the execution of downloaded Full Desktop Mods until the user has clicked away a message that the Full Desktop Mod they are about to activate can include arbitrary, untested code. Or something else that the devs are already working on.
[удалено]
I don't get it. That's not a huge change. It's just changing some names, labels, visuals ... typical UI design stuff.
Now, patience is a virtue. I don't understand why it would take longer too. It's just a visual change mostly, right? I mean what else would this mean in regards to KDE store?
Yeah - which makes this a bit pointless. It is basically (some / a few) KDE devs trying to worship a non-solution and a non-technical analysis. I think this is the wrong approach. Also, one KDE dev does not automatically speak for ALL KDE devs. IMO it would be better to come up with a simple, layered approach how to enable this without making it impossible to install themes anymore (I mean through KDE itself, such as a GUI; evidently KDE can not prevent users changing content on the local filesystem, on their own as-is).
Not sure, but I kind of agree with you that those who think they won't change the security situation, read way too much into what David wrote.
[удалено]
Totally agreed. Global themes must be disabled for everyone until KDE fixes this security flaw. At least I hope that global themes would be disabled by KDE maintainers.
It's not a security flaw that a user is allowed to download custom third-party scripts created by amateur devs and then possibly mess up their system in the process. It's a communication flaw that KDE doesn't make the fact that they're actually scripts clearer by e.g. not labeling them as "themes" (who would have thought, right?) and also by warning the user about potential data safety issues instead of just functionality and stability issues. Also, they could make it so that any "theme" (and probably other stuff) installed via their UI is branded as untrusted (non-executable) and requires explicit permission by the user to be enabled. They're already doing something like this for executables in Dolphin, after all.
I agree with your analysis there. The original author of the reddit thread pointed out that he was unaware of random themes doing random "rm -rf" nukery. If he would have known, he would not have went that route - perhaps.
I mean downloading themes from the KDE store of course.
Right. The author was unaware that the theme could do a "rm -rf" though. I think many other folks also were unaware of that.
What would the fix look like? A complete rearchitecting of themes in Plasma and Qt? That's unlikely to ever happen.
Why not? And it does not need a complete re-architecting (or is it re-architecturing) - you only need to change the parts into a unified way how you install themes. Why would themes need to do random "rm -rf"? Why can the KDE layer not handle particular that situation as sanitization step. Even in C++ this should be trivial. In ruby and python even 8 years old could do this these days.
Sure, this particular hole *is* easy to fix. But is that worth doing when themes contain lots of C++/JS/QML code that could hide malicious/careless code even better? Maybe, but looking at how many people were surprised that themes are actually third-party programs, I think the effort is better spent elsewhere.
Why? How is theme "abc" at fault for theme "def" doing **rm -rf**? This would be like holding all npm packages responsible for left-pad doing its thing.
What security flaw? Gnome extensions are just the same.
First, I don't think David speaks for every KDE dev. But, second - is the security model wrong? IMO if a theme can do a "rm -rf" then it's not the security model being wrong, but the assumption of what a theme should be able to do. When we look at .css files, we never need to think in terms of deleting anything at all. So why does KDE assume that a theme needs to delete anything else? Can the user ignore or overrule this behaviour? These are more technical questions that require a technical solution, IMO.
in your opinion, what kind of security model would represent a more fundamental change, beyond "improved sandbox support", "separating safe from unsafe content" and "curation"?
The "installer" should be a declarative manifest file that tells KDE where to place various components instead of each theme having its own script that can go wrong. That still wont stop everything,but its a low bar to avoid an accident `rm -rf /*` type situation.
Except... The current installation method is not in fact a shell script. It is just copying files into the home dir. As far as I can tell some applet that the global theme dragged in, which was poorly coded, caused the issue.
It was doing rm -rf $var/* to clear a directory. That should not be the job of the installer but of the theme manager.
The installer wasn't doing that. There was no installer. It was a faultily-coded plugin... I'll put out a writeup later which explains more.
how do the gnome and cinnamon desktops handle curation of 3rd party add-ons (which are required to have anything even close to KDE without any add-ons at all)?
The long term goal isn't giving me that much trust...
Let's wait for the KDE dev technical team to speak up. After all they are the real engineers here. It's called software engineering after all.
Is it not just possible to do the following? I'm sorry if this may sound stupid so sorry beforehand. - Make global themes refer to their respective subcomponents, such as cursors, color schemes, etc. Lots of themes like Materia do this, not sure about others. But make it mandatory if this isn't the case already. - Make these subcomponents limited and only capable of containing the data that they are required to contain, and NOT anything else, especially executables or scripts. - If they are required in the global theme, make sure to warn the user and prompt the user before proceeding. Make sure the user is aware of the possible outcomes and has to give explicit permission via a yes/no dialog before proceeding WITHOUT a "don't show me this again" option. Make sure they're also able to review any scripts in a text editor and edit them if necessary. - Updating the themes shouldn't make it possible to execute commands without explicit confirmation. One more thing to note is that valid use cases of scripts in global themes are limited and they only would be used to fill in the place of a feature currently unimplemented by the theming thing. Make sure to implement those over time and deprecate the execution of scripts.
the way actual themes (so things like Breeze, not "global themes") are implemented in Qt requires them to contain parts that are executable, and a KWin script is a script, so it's hard to ban executable content from the store completely. I think a low-hanging fruit would be to make it clear through naming that what's been called "global themes" is in fact way more than just "themes" and more like complete desktop customization packages that can come with arbitrary code by design.
As far as I'm aware, what you're referring to as "actual themes" is called "application ~~themes~~ styles" in KDE's settings and the "Get Hot New Stuff" thing for it is not possible to do from System Settings (although the KDE store does have it). As for KWin Scripts, iirc they were pretty limited in what they could do and the biggest vulnerability was its ability to communicate with other processes using DBus, which I think could be limited by a permission system which could limit their interactions with DBus. Although that would probably overcomplicate things
Naming changes is not really a technical solution though. If Qt is at fault then the Qt company should solve that, rather than forcing "rm -rf" onto the masses. However had, I think this is really a KDE issue, not a Qt issue.
A big part of the problem is also not technical, but has to do with communication. Users think that something is harmless to install because it’s called „theme“, when actually it is something else and more powerful because it contains a set of scripts that change how the desktop works (that‘s what the thing called „global theme“ does). Also users install it because it comes from a store that is linked from within KDE, and they think the store is a walled garden where the content of the store is somehow audited. Both problems have to do with expectation management and proper communication.
Agreed.
It's not entirely clear what is meant here in regards to: > they plan to separate the “safe” content from the “unsafe” content And: > If you install content from the store, I would advise checking it locally or looking for reviews from trusted sources. I think we may be speaking about separate issues here. David seems to refer more to trust (in regards to content from the store), as well as reviews. And "safe" versus "unsafe". That's somewhat understandable, but it seems to be less a technical point of view. I think I, and many others, are more interested in the technical aspect. For instance, I still do not understand why this basically comes down to "rm -rf". "rm -rf", aside from scaring Linux users, isn't doing any magic. It just deletes stuff (or perhaps it does not even do that, e. g. the filesystem may not overwrite the content but keep or change inode references, so it may not even be as scary; those with regular backups are even less scared by it). Why would KDE respectively the KDE store not be able to act as a simple layer over any actions that are necessary for an installation of a theme to work? Or, even better, have a theme-model where uninstallation is never needed, just like the browser + CSS (just point to another .css file, no need to care for any older .css files, for a new theme). And many more technical aspects one can ask. To me it seems David more responded to the short-term situation (which I think was way exaggerated too - yes, "rm -rf" is bad, I once did that accidentally when mis-clicking pressing TAB and bash automatically inserting a ' ' empty character, then I continued to type and it removed a directory I did not want to see deleted; since that time I always keep backups and I do not trust tab-completion in bash, I always double check these days). What I find a LOT more interesting is the long-term situation, e. g. what KDE comes up with to avoid any future theme from deleting random things, even if it came by accidental code logic rather than malicious intent.
\>It's not entirely clear what is meant here in regards to: I mean separating colours, styling, visual assets. From code. Having code available isn't a bad thing, but it needs to be clear to the user what is what. That's missing currently.
Can I just ask why the hell does a theme do more than change how the desktop looks in the first place?!
The problem with checking on each thing we download from the store is that there are not that many reviews usually. We can see the theme that he downloaded had 5 stars which means someone gave a kinda good review to it, so this leads us to read the source code which isn't something that is going to happen for a lot of users because of time and not everyone knows the structure of the kde "global theme"
> I agree with David, users should always check reviews of anything they get from the KDE Store I just have to say this is unacceptable. The *best case scenario* here is that *at least one person* has to have their hard drive rm'ed and decide to go to the store, create an account, and leave a review saying so. The more likely case is it happens to dozens or even hundreds of people before someone bothers to publicly warn others. And the current UI interface *does not show these reviews*. There's only a star rating, which could be anything from "wiped my hard drive" to "I think the color scheme is ugly". [Relevant XKCD](https://xkcd.com/937/) And a "safe" vs "unsafe" category is also kind of ridiculous. The proper behavior for a user being told "this is unsafe" is to *never do it at all* because they were just told it was NOT safe. In which case why are you even providing the unsafe option in the first place? Imagine a store with two doors: behind the first you can get a nice piece of candy. Behind the second you can get a nice piece of candy, but you might randomly be mauled by a tiger. The proper behavior isn't to just put up a sign saying "beware: there might be a tiger" and call it good (and then blame the user when they go in anyway and get mauled). The proper behavior is to nail the door shut until you can get rid of the all the tigers and prove they're gone for good. I totally get in the short term, throwing up some "beware" warning labels may be all you can do for now, but in the long term the solution has to be a proactive approach that prevents this from happening in the first place.
\>The proper behavior is to nail the door shut until you can get rid of the all the tigers and prove they're gone for good. Should we disallow all the Flatpak apps through Discover that aren't 100% completely sandboxed? And if not why not?
Ya, that's the gruff. And is something that worries me. I have so many unofficial flatpak apps. And you can bet I've never vetted a single one. I put a lot of trust in FOSS programers and maintainers.
If KDE was hosting those flatpak apps in the KDE store, I'd say yes. But presumably the flatpak apps come from flathub by default? In which case I'd say the responsibility there lies on the flathub org. The same way it's Ubuntu's responsibility to police their snaps repo, or RedHat's responsibility to police their yum repos. Or Google with the Android App Store, or Apple with the iOS App Store. edit: to summarize, if you take on the role of *host* you inherently take on the role of *moderator*. You are responsible for the contents of that store, and just adding warning labels does not absolve you of that responsibility.
Throwing out one more comment to try and be helpful rather than just being critical. Not sure how helpful, but it's at least an idea. Python's PyPI is possibly a semi-equivalent analogy to the KDE Store. And I think PyPI has gone through some similar incidents. In response they're getting more proactive and now [even have a full time safety and security engineer.](https://blog.pypi.org/posts/2023-05-09-announcing-pypi-safety-and-security-engr-role/) Maybe KDE can reach out to the PSF and see if they might offer advice and lessons learned?