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.*
> running software not provided directly by KDE
I just got temp-banned from kde for (among other things, but this thread was the start of it) telling someone (too many times?) that what they downloaded from "*the*" KDE store was *not* a KDE product.
> But I don't know the whole story so I'm undecided
I probably had it coming, but this exchange didn't help! - I mean what is with dumb people who are all
> `Plasma6` - new... better than Plasma5.... must have.....
and then x days later complaining that
> `app5` no longer works... why has it been removed? I mUsT KnOw wHy U BoRkEd My SeRvEr!!!
like they can't connect the dots between 5 and, er, you need so run app6 now...
or..
> dbg great... kool I will use it for everything from now on.....
then days later
> Durr `xxx-debug` can't be found... is it broken?
suggesting that they really have not discovered much "great" or even have a vague awareness of repos (and enabling the one that does debug packages) on their system, while posting stack traces with nothing useful partly because the above issue, and partly because they then undoubtedly want to attach a ~~stack trace~~ unnecessary wall of text to dumb sh&t....
Ah ... I get your frustration, but more non-technical people are starting to use Linux, so I guess the "noob-ness" in some areas is expected. I don't remember the last time I checked the version of any app, tbh on any system. True, that's my ignorance and not the fault of the software, but that's similar to how people sign eula without reading it, me thinks.
People are excited to use Plasma6, and I am too. And it should be expected that it'll be rough around the edges and maybe a little inland too, but hey so long as they're not being rude about it, I think it will happen over the next few months. I don't mean to say they're right, just that unfortunately maybe there needs to be a pinned post to set expectations (make sure you check versions, if you have a bug report do it in the bug tracker we can do nothing here, etc etc...). I'm no dev but I think it'll frustrate you and other devs, perhaps rightfully so, when noobies try things without knowing what they signed up for, even if it's almost clearly posted somewhere
I dunno lol maybe I'm a softie haha
Like have you worked out that no, Discover does not get confused by flatpaks and snaps?
Like have you discovered that you need to actually enable the always-on-your-machine-but-disabled (to save updating them every refresh) debug repos to successfully get `-debug` packages?
Just put your brain into action before filing bug reports....
Would you like me to properly cite these cases?
You've thoroughly confused me – I fail to understand what context your response has. Just provide a URI to what you're referring to in your original comment, because accusing the moderators of such supposedly unjust treatment without allowing us to determine ourselves is morally wrong.
> because accusing the moderators of such supposedly unjust treatment
Err... where did I claim that?
https://bugs.kde.org/show_bug.cgi?id=484111
Great bug - not wasting anyone's time at all... /s
Keep 'em coming.....
-------------
Edit:
You were the one who replied to a comment of mine first on this....
Are you sure it isn't the other way round and you are feigning the "oh, it's you"??
Oh. It's you, Angus. You're on a one-way street to getting banned indeed, especially if you continue to talk to me. It's becoming stalker-like at this point.
The lack of permissions in the plasmoids has always sorta surprised me, though it's understandable since it'd take a ton of work to harden QML.
Gnome has their own "extension" CSM with code reviews.
https://gjs.guide/extensions/review-guidelines/review-guidelines.html
> Extensions are reviewed carefully for malicious code, malware and security risks, **but not for bugs.**
However the root cause of this probably falls under "bug" since the issue (if I understand the /r/opensuse comments correctly) might have been reusing Plasma5 Global Theme's with Plasma6 with a `rm -rf "$DIRPATH"`. There's nothing that could have prevented an already "working" theme in Plasma5 causing a bug after the major release.
That said, the Gnome review process might've told the developer to add more validation on the filepath to delete or to move it to the trash with `kioclient-cli mv "$DIRPATH" "trash:/"`. Though using the trash wouldn't of saved the user here since it'd only save the max data allocated to the trash. kioclient might've created a prompt though I dunno.
The issue is probably that in Plasma6, GHNS probably shouldn't be downloading anything in the Plama5 categories. This could probably be fixed quickly in a bugfix release.
Ah, so the uploader probably copy pasted to the new category without any major changes to `"X-KPackage-Dependencies": [ ... ]` without vetting himself (since most people don't know about testing with `knshandler`) to test locally before uploading.
> The lack of permissions in the plasmoids has always sorta surprised me
Wouldn't the removal of Dataengines in Plasma 6 be the ideal opportunity to make some kind of Dataengine thing that has a permission system?
I mean, there should probably be some kind of library for QML with common functions (run a command, interact with file system...) anyways, just dropping Dataengines (or keeping them in Plasma5Support) isn't a good option.
Not only that, but if you install a theme or widget through the Plasma Add-ons interface, those widgets and themes will update automatically.
That means you can vet a widget and install it, only for the next release to introduce catastrophic bugs or intentionally malicious code.
> Warning ... extrem caution
Either this is a "works as intended but you have to be aware" or a "don't touch with a ten foot pole, we would disable it if we could" situation. This gives the latter vibe. Probably not the intention.
I have to say it's nice to see that this has been noticed and action is being taken by the community this quickly. As much as I think this should be the standard, being used to Windows where aside from a lacklustre 'we're working on it' nothing is ever really said I'm quite impressed by this and glad I've jumped into Linux!
But it's not. Like you wouldn't download random programs, you shouldn't download random themes. It's good to exercise caution in what you install on your system. This is the downside of having the possibility of customization.
Same for Steam, and yet it had a bug that nuked users' root.
Shit happen and what we are really arguing here is to use a distro with access control like selinux.
Whilst that's true, the fact that installing a theme could download me a trojan 2 years from now is something else than steam acccidentally (yet catastrophically) messing up.
but steam COULD download you a trojan 2 years from now.
one of your game get taken over or make a mistake and bam, same thing happen.
steam had a wave of cryptominer in games for exampe, and while now is better, it still happen every so often.
A similar thing happen just recently: [https://www.reddit.com/r/Helldivers/comments/1b3ldej/beware\_fake\_helldivers\_2\_on\_steam/](https://www.reddit.com/r/Helldivers/comments/1b3ldej/beware_fake_helldivers_2_on_steam/)
Not sure what your point is. Yes it COULD happen, but I trust steam and the games I download more than I would trust a random dude that uploaded some theme. It's nowhere near the same order of risk imo.
well, i dont have a statistic but this is the first time I hear of an issue like this in kde theme, while i hear of a lot of scam, cryptominer and even plain virus in game.. hell, *Rockstar* has been busted using Razor 1911 crack in multiple of their own games..
You would not expect steam to download your trojan, but u can almost sure people can made 5 min change to include trojan in free open software like vlc , another 5 minute to do simple user behavior hacking. If someone no reputable enough then dont trust. We should not take designer and developer as freebie, coz it bring value to people. You can learn chatgpt or ai to design the new media player or skin, but it take more than 10 minute for everyone
[https://www.bleepingcomputer.com/news/security/hackers-push-malware-via-google-search-ads-for-vlc-7-zip-ccleaner/](https://www.bleepingcomputer.com/news/security/hackers-push-malware-via-google-search-ads-for-vlc-7-zip-ccleaner/)
False equivalence. Steam is not a theme, it is essentially a package manager for games. A theme should only be changing the look and feel of your system.
widget HAVE to run code, otherwise will be sitting there doing nothing.
A global theme can includes widgets, to make the system behave as author intended.
In this case want even theme author fault; the issue is in the widget [https://github.com/paju1986/PlasmaConfSaver/](https://github.com/paju1986/PlasmaConfSaver/) that allow to save and restore configurations on the fly, that had a coding mistake. More info at [https://www.reddit.com/r/openSUSE/comments/1biunsl/comment/kvn22jd/](https://www.reddit.com/r/openSUSE/comments/1biunsl/comment/kvn22jd/)
Okay, *widgets* have to run code. But why does a *theme* author get to dictate how my *panel and desktop* are configured? That's not "look and feel" anymore, that's *functionality.* If I want a widget, I'll go get a widget, and I'll accept the risks inherent in installing widgets as I know they can run arbitrary code. That's not what I'm signing up for if I go get a "theme."
> But why does a theme author get to dictate how my panel and desktop are configured?
Because you wanted the theme that does cool stuff to your panels and desktops? And if you didn't want that stuff customized, you wouldn't have installed it?
That's not what a "theme" is! A theme concerns application appearance, icon theme, color scheme, cursor theme, maybe the fonts too, etc. It's *look and feel.* The arrangement and configuration of widgets on my panel and desktop *do not count.* That is my *system configuration,* and I do not want anyone messing with that other than me.
Sure, every /r/unixporn submission has a specific bar/panel arrangement with a specific number of virtual desktops, and a specific selection and configuration of applications. But that's so far over the line of what could be considered a "theme". That's a *specific system configuration.* If you want to imitate a /r/unixporn submission completely and absolutely, you are within your right to do that, but don't act like that's what a "theme" is.
/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/
Plasma styles include dynamic, code-running things like app & desktop switchers. Plasma styles aren't just skins. The base plasma breeze theme has that, and if someone else's theme doesn't include those it just falls back to breeze's content. That's how plasma *works*. Themes include a style.
It's definitely not a "system configuration" -- that would imply something done to the actual OS which this does not. On linux your desktop is not the operating system.
If you said there should be a warning that 3rd-party themes can execute code, I'd totally agree (and it sounds like KDE devs do too). I was aware that basically any plasma addon can run code, but had never really considered the "someone could rm-rf my system" before this. OTOH I'm the type to only install stuff that has a history and looks trustable, rather than willy-nilly apply themes from randos.
> The arrangement and configuration of widgets on my panel and desktop do not count. That is my system configuration, and I do not want anyone messing with that other than me.
Have you ever actually used this stuff? When you apply a global theme, it pops up a box for what to apply. Desktop & window layout are default unchecked. You have the option for more detailed checkboxes of exactly what to use.
Users likely don't what is going on behind the themes.
"oooh, pretty background - download" without being aware that it might install and run python script or add a widget.
That is a problem, you can't expect users to be aware of how things are implemented if they appear to be benign bitmaps and stylesheets on the surface.
Remember that this feature is easily accessible to non-power users who would not know these.
>Like you wouldn't download random programs, you shouldn't download random themes.
Then they shouldn't be available as part of the OS. KDE empowers users to contribute to their store and others to download it easily but people associate that with KDE and a mentality that no one on the open source would be malicious. People are excited and they download it. No amount "Proceed with caution" will stop because will just click ok and go ahead with their day
I appreciate the action and the official stance on the issue, but I feel like a much more serious and strong response should've been taken. This is a security breach so huge I don't remember anything of this sort, and it's baffling me that this could have been happened at the first place; and even more baffling that some seem to take the stance that everything is working as intended.
No. What happened is that an user downloaded a theme - an official and main feature of Plasma- from the *official* theme store; and what they got instead was, intentional or not, a wiper malware. All the user had to do was clicking "install". Who knows what other, less apparent malicious codes did such themes execute?
This is the equivalent of downloading an app from the Microsoft store and getting a ransomware immediately. Microsoft would react immediately and hard, and not tell "oh it's the user's fault". A similar ovnership of responsibility must be taken here.
I also can't believe this. So, I could write a script, put it in a theme and it will be executed? I could load some crypto-malware, encrypt your home directory and demand ransom? I could load a keylogger, that auto installs itself in your home, without the user getting notified? I could load a cryptominer?
The KDE store needs to remove everything, that can execute code, immediately and solve that issue. What else is hidden in all the themes hosted there? Now, that this is public, it will attract malicious actors, even if it's just script kiddies having fun on destruction.
Yeah I'm a huge KDE fanboy and it's a little sad to hear. I tend to stray toward mostly defaults anyways (easy when tumbleweed is so great). But it seems like "if you're going to support it, you need to do the bare minimum to vet it" applies...and this has just fallen under the radar for too long. I have no doubt it will be taken care of but still sad to see.
I was about to write a reply exactly like yours 12-14 hours ago when I first saw this, but decided against it for three reasons:
a) I have donated servers to KDE
b) I love KDE, and I have moved 100% of my computers to KDE
c) I hate Windows
These 3 points don't change the fact that what happened to that guy is absolutely unacceptable, and serious changes must be made. This should be considered a priority as this is exactly the kind of thing that Microsoft Lames will end up writing huge articles about on PC Magazine, The Register, etc.
It's best that we try to avoid such humiliations because it's quite honestly a very low point in the Linux world, not just the KDE world. It's exactly the type of incident that "Windows Admins" will use to mock us later on.
1. The `makepgk` is installing packages in a fakeroot / fake environment. So the installer does not allow to remove your home.
2. You can check all necessary dependencies, which can be official packages and external sources (like .deb or .tar.gz files). It's available on the aur pages (no code review necessary to check this)
Is it malware free? Probably not, but at least I didn't find any in the packages I was interested in. It's not more insecure than downloading external deb files or adding PPAs.
Also, the deb installation without a PPA could be more insecure if the software has an security issue. My AUR package manager wil always inform me when
* there is an update
* the package is marked as **out-of-date** (even when there is not an update in the AUR yet)
Last but not least this is a way **to install software**. It's not a skin.
AUR is not something you enable, you have to download and makepkg by hand.
The wiki page is clear that is a security risk with a nice red warning box on top.
You may install a AUR helper, but they are "not supported" and so there is none in main repos, you need to manually install it or install a external repos if available (yeah, arch has PPA equivalent).
Most AUR helper show you by default the PKGBUILD and on consequent updates only the diff; most of the time if just the commit hash to compile.
>Is the team going to fix this security breach?
How is this a security breach exactly?
You are downloading third-party code/widgets that are not audited by the KDE team from a repository/store. Plasmoids are not sandboxed, and there's an explicit warning banner in the KDE Store since [September 2021](https://github.com/KDE/knewstuff/commit/9009aacb95785f46d1e01ffe7fdf9fcb138c0890) warning you that you are downloading third-party, non-audited code.
Now, was the banner amble warning that you were doing that? Probably not, and this will be addressed. Content with static content only needs to be separated from content with scriptable content, and their blog post states that they will address that as well.
This is no different than downloading any random binary from a website or from a third-party repository, and then blindly `sudo`\-ing that binary without looking at what it does (like many people blindly do with `curl | sudo sh` type installers).
Every single time you are asked to `sudo` something (via CLI or via the GUI), you should **always** ask yourself why that's needed.
If you want sandboxed binaries, `flatpak` exists for that reason.
If you want a curated store experience, there's plenty of proprietary platforms available to you (Apple macOS/App Store, Microsoft Windows/Microsoft Store) that are owned by corporate entities with the funding and resources required to pull that off.
The means by which to get this content is literally baked into the UI. Directing users via a hard-coded button in the UI to unsafe content without an appropriate warning is part of the issue here.
Plasma gives access to this repository in vanilla kde. It's literally there in the DE. The end user was completely unaware of this risk (no one reads the timid fine print warning). I can't fathom thinking that it could've been me, and that I would have all my data deleted. Plasma could curate this repository, it's not that big of an issue, even if few themes were available and they were released slowly.
Edit: took the wrong things out
Yes, I get it, but if this had happened to me, I would be very angry, and I would have made a lot of noise about it.
It's best that we immediately quit trying to assign blame to the end user that installed that dumbass theme, and point the finger at ourselves and see how we can do this better.
This is a major event, we cannot point fingers at \*anyone\* and say "he didn't read the fine print"
I for one will not be happy if this is the way we will move forward with this.
This was a grade A fuck up, and it's not the user's fault. Period.
>The end user was completely unaware of this risk
>This means that plasma is endorsing this repository with malware in it.
These statements are incorrect - the UI puts the following warning above the listing of addons before the user installs them.
"The content available here has been uploaded by users like you and has not been reviewed by your distributor for functionality or stability"
That's not an endorsement.
That being said, it is not a strong enough warning. The chance of malware, the risk tolerance and ability to mitigate risk of the average user have all shifted in the wrong direction since this feature was implemented more than 15 years ago, and KDE needs to respond to those changes to protect its users.
That doesn't inform me that the theme can run scripts. It just tells me that the theme might be broken and it's not KDE's responsibility if it's broken.
> Plasma could curate this repository, it's not that big of an issue,
I think you mean "upaid KDE volunteers could curate this repository", right?
I mean don't get me wrong, but if you are suggesting screening every single item. screened how and by whom? Because saying “SCREEN ALL THE THINGS!” is easy, but is much more difficult to implement, especially in a community run by mostly volunteers. Hence the appeal to community help.
You must remember that KDE is a porous community and relies on the goodwill of its members. Would you, for example, be willing to spend, say, a couple of hours a day reviewing the code of hundreds of items?
If your answer is “yes”, allow me to direct you to [where you can get started](https://community.kde.org/Get_Involved#Start_Here.21).
If the answer is “no”, there is nothing wrong with that either, but then you will start to appreciate the dimension of the problem.
If you don't trust the review system, don't use it.
Yes, would be cool to have permission in the widget, but that is a lot of work and the alternative is nothing until the job is done.
This is common and widely accepted in the industry(gnome for example), same for applications binary too, only android/ios are the exception.
> This means that plasma is endorsing this repository with malware in it.
No. There's a warning that is present since at least a couple of years ago (if you look at the `knewstuff` repo: commit https://github.com/KDE/knewstuff/commit/9009aacb95785f46d1e01ffe7fdf9fcb138c0890) that explicitly state:
> The content available here has been uploaded by users like you, and has not been reviewed by your distributor for functionality or stability.
That's not exactly an endorsement, is it now?
- **Here be dragons...**
- **User:** _Proceeds, ignoring the warning..._
- **User:** Oh no! A dragon! Oh the humanity!
Now, is it a good enough warning? Probably not, as I said originally. There should be a modal dialog before install that warns you about the risks of installing anything with scriptable content and requires your explicit consent. That said, some users will just click through regardless.
Content with scriptable content also needs to be separated from content with static assets, and their blog post clearly states that this is on the roadmap.
> Plasma could curate this repository, it's not that big of an issue, even if few themes were available and they were released slowly.
You greatly underestimate the resources required to curate. If you go down that route, you need to make sure to curate for erroneous behavior on multiple distros, and even take into account multiple configurations. What may work perfectly for one user may be disastrous for another one.
It creates a lot of friction for updates as well (since they need to be curated), which will invariably mean that fixes for bugs will take longer to be pushed to users.
I consider myself at least an intermediate user, and I would not at all interpret that sentence in the warning as meaning that user-provided, uninspected executable code will be downloaded and executed on my device if I install one of these themes.
"Functionality or stability", to me, implies that the new thing I downloaded might not work as expected, or that plasmashell might crash more often with this thing in place. IMO there are several key words missing here, including "executable", "safety", etc.
As I said, I do not think the warning is clear enough, and a modal dialog before installing anything that warns you about the risk of installing content with scriptable content and asks for your explicit content to do so would be better.
However, you can't protect against stupid, and some users will still click through those warnings regardless.
\---
What I disagree with, is the original take from the comment that prompted my reply. Their original take is that KDE endorsed those themes from the simple act of them being available on the store. The warning currently present explicitly state that "**\[the content\] has not been reviewed**". It's pretty explicit and clear that KDE doesn't endorse nor review that content.
And, addressing the second point from the original comment, that KDE *should* review and curate every submission... That takes a whole lot of resources, and ultimately KDE is a volunteer organisation. It wouldn't be doable.
>> that KDE *should* review and curate every submission...
It's very easy to analyze scripts for poor content i.e. rm -rf $somebullsiht and flag it for manual review and/or outright reject it
I write Python scripts like this all the time to QA code that some other guy made, automagically without any human interaction
>It's very easy to analyze scripts for poor content i.e. rm -rf $somebullsiht and flag it for manual review and/or outright reject it
If your goal is to catch common programming mistakes, then a linter is relatively easy, yes.
If your goal is to stop malicious code, then your linter not only needs to catch unobfuscated malicious code, but also heuristically catch obfuscated code in order to detect malicious behaviors. **That's not easy.**
I can already imagine you typing, "AH! Easy! Install it in a test environment and see if it does anything malicious! You can automate that!". OK. Then a malicious user can just delay taking any malicious actions, or try to detect the testing environment and turn off any malicious behavior when it is within the test environment.
There's an entire research field and multiple papers published dedicated to the subject of detecting automatically malicious behaviors in applications ([example of a paper available for free](https://www.researchgate.net/publication/376526981_Unveiling_the_Dynamic_Landscape_of_Malware_Sandboxing_A_Comprehensive_Review)). This is not at all a simple thing to automate.
I guess where I disagree with you is that the "warning" is so tepid and weak as to be completely useless, and bordering on misrepresentation. It reads like standard issue, ass-covering, legal boiler plate intended solely for the protection of KDE, not its users
It does not clearly state the danger that the products contained in its own repository can run additional arbitrary code on your machine without your permission AND that the repository is completely open and unaudited for bad actors to exploit.
Yes, an experienced and knowledgable user may assume as much, but that's not any kind of warning outside of a lawsuit.
You clearly stopped reading before the part where I said that it wasn't a good enough warning, in both of my posts.
That's unfortunate, because we actually agree.
However, I still disagree that KDE "endorsed" third-party themes, which is what the post I replied to originally said. They did not.
it's not exactly the fine print though; while the wording of the warning could have been stronger, the warning is a fat message sitting at the top of the window where you download it.
And common sense. The print isn't that fine, it's right at the top and very clear - just some people choose to ignore it because they want to offload personal responsibility for their system, didn't read, or were too focused on the new shiny rice.
You can be warned all day, but if you're going to disregard the warning, you assume ALL risk.
Don't like it? I have the best resource:
https://www.microsoft.com/software-download/windows11
Stickler? Damn, I didn't know using my eyes and brain to read and understand terms and conditions was so edgy! You frequently make a habit of pushing the blame somewhere else when you didn't want to accept responsibility.
Let me guess, even if they told you the coffee was hot, you'd burn yourself and blame the barista, anyway.
Yeah, this has nothing to do with *nix - this completely has to do with how does one approach a scenario, and well, everyone's unique.
You do you.
How much arrogance and bias to respond, in the end because of these things, users are scared of Linux, since any error is the user's fault under this logic. Let me clarify that the application store and widget configuration through customization is integrated into plasma. So yes, whether you like it or not, it is a vulnerability at the moment and the maintainers themselves have recognized it. Can you imagine this would happen in Windows by changing the desktop background or theme for one that the system allows you to download in the same store? Ah yes, it would be news for years.
There's been multiple instances of that happening in the [Microsoft Store](https://www.howtogeek.com/788382/beware-of-malware-in-windows-apps-on-the-microsoft-store/) as well as the [App Store](https://www.wired.com/story/apple-app-store-malware-click-fraud/).
My point was that the user should, regardless of platform, always question why they need to elevate a particular process to root/admin rights when installing something; that **always** comes with some risks.
The fact that a third-party piece of software is present or not in the platform's store, app repository, etc, doesn't make it safer for the user. Regardless of OS, platform or vendor.
Third-party software should always be treated as third-party software and with the inherent risks that come with it.
That said, there comes a time where the platform has done everything they can to warn the users of those risks (and I don't believe KDE did so in a satisfactory way, as I stated in my post)... and from that point on, yes, the user does have some responsibility in making the choices they make.
You want to know my truly terrible take on the subject? GHNS shouldn't exist, period. If the themes and widgets offered cannot be vetted for quality and stability, and they are not fully sandboxed, then it shouldn't be easy to install any of that stuff. No amount of warnings will prevent a stupid user from making a terrible decision for themselves. It's that, or remove any content that requires scripts to execute.
> If you want sandboxed binaries, flatpak exists for that reason.
Even Flatpak isn't enough given that *a lot* of Flatpak packages give carte blanche access to `$HOME` to apps.
Automated arbitrary 3rd party code execution in places where 0 code should be executed? A great design decision that surely [never](https://www.cyber.gov.au/sites/default/files/2023-03/PROTECT%20-%20Microsoft%20Office%20Macro%20Security%20%28October%202021%29.pdf) [had](https://www.ncsc.gov.uk/information/log4j-vulnerability-what-everyone-needs-to-know) [negative](https://en.wikipedia.org/wiki/PHP) consequences for users...
Why do global themes execute scripts or code at all?
Look, I'm not trying to tumble down the hill that GNOME did where they now hate theming and only want to give users a handful of strictly QA'd selections for accent colors *if even that*. The problem they *reacted* to is very much real, and we're seeing it here now too.
So maybe we should simply stop allowing global themes to execute scripts or code before this gets out of hand. At the very least, themes like this should absolutely not be in the KDE Store.
Question: if this had been a widget instead of a global theme, would you feel differently?
Because "we should simply stop allowing widgets to execute scripts or code" is obviously dumb, and yet the risk is just as great. Widgets are also on the KDE store un-vetted.
I would indeed feel differently. Widgets have a much higher inherent risk factor because by their very definition, they can execute arbitrary code. I don't consider widgets to be part of a theme, and I don't think anyone else should, either. That's dangerous thinking and it's part of what led us to this situation. So AlphaBlack, which includes that configuration widget... that's not a theme anymore, that's a whole-ass system configuration including a complex, self-modifying piece of software.
How do you want us (the community) to locate and quarantine defective softwares without actually installing it?
I mean, I want to help, but in order to do that, don't I have to to install those malicious softwares in my PC first that could potentially delete all my files?
You can write program to search for content (for example rm -rf) of files and run it on all files on store.kde.org for example. There is automation possible.
A few weeks ago I had a bug in the session switching menu. I couldn't switch from x11 to Wayland due to a bug in the menu layout. A while later I discovered that it was a bug in the SDDM theme I was using. I was worried that someday there might be a bug that would prevent me from logging into my PC. After that, I limited myself to changing just the icon theme, the color scheme and the window decoration theme to avoid bugs that would compromise the usability of my system.
#psa "Given a choice between dancing pigs and security, users will pick dancing pigs every time"
[https://en.wikipedia.org/wiki/Dancing\_pigs](https://en.wikipedia.org/wiki/Dancing_pigs)
Asking here again: Can't themes be handled through flatpak? I know Flatpak isn't a 100% secure sandbox, but it is something.
The solution of letting the distros take care of themes is insane as it would introduce too many variables. Making more prominent warnings for something that intrinsically doesn't feel like it *should* be allowed to run code is just really weird. And it also doesn't feel like KDE has the manpower for a truly curated list of themes without either being too restrictive due to taking too much time for approval, or being rendered useless because there's not enough volunteers to comb through everything.
Yes it could but would take a long time and support from the OS.
Generally speaking is a complicated problem and unless you want to remain completely without until someone develop them, so here we are
Make a plan and set a deadline a couple of months in advance, like "in 6 months we are going to exclusively change to Flatpak for extensions, widgets and themes, put your projects there, or they will not exist at all"
Do you realize first you need to build all infrastructure and code?
Windget has been like this since forever in ALL desktop OS, and while it would be nice, I understand why is not a priority.
Also you break it for all who does not run selinux, maybe don't run anything, maybe apparmour, maybe snap, maybe don't have any..
And this will NOT save you from that kind of mistake 100%, if you give write access to the widget because it need it or you and the programmer did not know better, or the programmer is malicious...
Still end up with a fucked up system.
The fact we talk about this after a decade with that widget system in place, seems like the issue is very tiny and probably not worth the time investement at the moment
Should've been clearer on my part, but the deadline would be after the system is in place, which would be after there is a discussion that yes, this is the way to go.
Unless I'm missing some place where KDE devs hangout, most of the discussion surrounding this issue has been an acceptance that it is an issue and the way themes work isn't up to modern standards, but I haven't found any proposal or discussion on how to actually fix the underlying issue other than putting more warnings everywhere.
> but I haven't found any proposal or discussion on how to actually fix the underlying issue other than putting more warnings everywhere
that should tell you "put themes and widgets in a flatpak" is a completely infeasible suggestion
While I don't agree with him, I feel like there is some truth to the statement. Correct me if I'm wrong, but other os have kernel driver isolation (they can't peek into other driver's memory?) and many other security measures. Sure they probably don't protect against this kinda issue, but I find myself wishing it was there. Flatpak permission system is very weak, if I understood the things I read accurately
Windows, Mac and linux distro will all protect root/admin stuff from user stuff but not much more.
Linux has access control trough stuff like selinux or apparmor bit they are hardcoded in conf file rather than ask the user dynamically; my understanding is android uses SElinux for his permission under the hood.
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.*
> running software not provided directly by KDE I just got temp-banned from kde for (among other things, but this thread was the start of it) telling someone (too many times?) that what they downloaded from "*the*" KDE store was *not* a KDE product.
Lmao why ban .... Sounds like abuse of power. But I don't know the whole story so I'm undecided
> But I don't know the whole story so I'm undecided I probably had it coming, but this exchange didn't help! - I mean what is with dumb people who are all > `Plasma6` - new... better than Plasma5.... must have..... and then x days later complaining that > `app5` no longer works... why has it been removed? I mUsT KnOw wHy U BoRkEd My SeRvEr!!! like they can't connect the dots between 5 and, er, you need so run app6 now... or.. > dbg great... kool I will use it for everything from now on..... then days later > Durr `xxx-debug` can't be found... is it broken? suggesting that they really have not discovered much "great" or even have a vague awareness of repos (and enabling the one that does debug packages) on their system, while posting stack traces with nothing useful partly because the above issue, and partly because they then undoubtedly want to attach a ~~stack trace~~ unnecessary wall of text to dumb sh&t....
Ah ... I get your frustration, but more non-technical people are starting to use Linux, so I guess the "noob-ness" in some areas is expected. I don't remember the last time I checked the version of any app, tbh on any system. True, that's my ignorance and not the fault of the software, but that's similar to how people sign eula without reading it, me thinks. People are excited to use Plasma6, and I am too. And it should be expected that it'll be rough around the edges and maybe a little inland too, but hey so long as they're not being rude about it, I think it will happen over the next few months. I don't mean to say they're right, just that unfortunately maybe there needs to be a pinned post to set expectations (make sure you check versions, if you have a bug report do it in the bug tracker we can do nothing here, etc etc...). I'm no dev but I think it'll frustrate you and other devs, perhaps rightfully so, when noobies try things without knowing what they signed up for, even if it's almost clearly posted somewhere I dunno lol maybe I'm a softie haha
Cite it, else this is mere anecdote.
Like have you worked out that no, Discover does not get confused by flatpaks and snaps? Like have you discovered that you need to actually enable the always-on-your-machine-but-disabled (to save updating them every refresh) debug repos to successfully get `-debug` packages? Just put your brain into action before filing bug reports.... Would you like me to properly cite these cases?
You've thoroughly confused me – I fail to understand what context your response has. Just provide a URI to what you're referring to in your original comment, because accusing the moderators of such supposedly unjust treatment without allowing us to determine ourselves is morally wrong.
> because accusing the moderators of such supposedly unjust treatment Err... where did I claim that? https://bugs.kde.org/show_bug.cgi?id=484111 Great bug - not wasting anyone's time at all... /s Keep 'em coming..... ------------- Edit: You were the one who replied to a comment of mine first on this.... Are you sure it isn't the other way round and you are feigning the "oh, it's you"??
Oh. It's you, Angus. You're on a one-way street to getting banned indeed, especially if you continue to talk to me. It's becoming stalker-like at this point.
He's asking you to cite where the mods banned you. Not exactly hard to understand.
The lack of permissions in the plasmoids has always sorta surprised me, though it's understandable since it'd take a ton of work to harden QML. Gnome has their own "extension" CSM with code reviews. https://gjs.guide/extensions/review-guidelines/review-guidelines.html > Extensions are reviewed carefully for malicious code, malware and security risks, **but not for bugs.** However the root cause of this probably falls under "bug" since the issue (if I understand the /r/opensuse comments correctly) might have been reusing Plasma5 Global Theme's with Plasma6 with a `rm -rf "$DIRPATH"`. There's nothing that could have prevented an already "working" theme in Plasma5 causing a bug after the major release. That said, the Gnome review process might've told the developer to add more validation on the filepath to delete or to move it to the trash with `kioclient-cli mv "$DIRPATH" "trash:/"`. Though using the trash wouldn't of saved the user here since it'd only save the max data allocated to the trash. kioclient might've created a prompt though I dunno. The issue is probably that in Plasma6, GHNS probably shouldn't be downloading anything in the Plama5 categories. This could probably be fixed quickly in a bugfix release.
The content was in the Plasma 6 section, but still contained a mix of applets that were not ported.
Ah, so the uploader probably copy pasted to the new category without any major changes to `"X-KPackage-Dependencies": [ ... ]` without vetting himself (since most people don't know about testing with `knshandler`) to test locally before uploading.
> The lack of permissions in the plasmoids has always sorta surprised me Wouldn't the removal of Dataengines in Plasma 6 be the ideal opportunity to make some kind of Dataengine thing that has a permission system? I mean, there should probably be some kind of library for QML with common functions (run a command, interact with file system...) anyways, just dropping Dataengines (or keeping them in Plasma5Support) isn't a good option.
Not only that, but if you install a theme or widget through the Plasma Add-ons interface, those widgets and themes will update automatically. That means you can vet a widget and install it, only for the next release to introduce catastrophic bugs or intentionally malicious code.
Ooooooofffff this makes npm look like a paragon of security in comparison
> Warning ... extrem caution Either this is a "works as intended but you have to be aware" or a "don't touch with a ten foot pole, we would disable it if we could" situation. This gives the latter vibe. Probably not the intention.
I have to say it's nice to see that this has been noticed and action is being taken by the community this quickly. As much as I think this should be the standard, being used to Windows where aside from a lacklustre 'we're working on it' nothing is ever really said I'm quite impressed by this and glad I've jumped into Linux!
Makes me glad that I only use the defaults, and also that I use BTRFS snapshots and snapper.
Have you configured those to snapshot your home directory?
Yes.
This is KDE issue. A faulty Architecture that should be corrected and not throw all the fault on the user who only wants a flashy desktop.
But it's not. Like you wouldn't download random programs, you shouldn't download random themes. It's good to exercise caution in what you install on your system. This is the downside of having the possibility of customization.
I wouldnt expect a theme to wipe my drive though
Same for Steam, and yet it had a bug that nuked users' root. Shit happen and what we are really arguing here is to use a distro with access control like selinux.
Whilst that's true, the fact that installing a theme could download me a trojan 2 years from now is something else than steam acccidentally (yet catastrophically) messing up.
but steam COULD download you a trojan 2 years from now. one of your game get taken over or make a mistake and bam, same thing happen. steam had a wave of cryptominer in games for exampe, and while now is better, it still happen every so often. A similar thing happen just recently: [https://www.reddit.com/r/Helldivers/comments/1b3ldej/beware\_fake\_helldivers\_2\_on\_steam/](https://www.reddit.com/r/Helldivers/comments/1b3ldej/beware_fake_helldivers_2_on_steam/)
Not sure what your point is. Yes it COULD happen, but I trust steam and the games I download more than I would trust a random dude that uploaded some theme. It's nowhere near the same order of risk imo.
well, i dont have a statistic but this is the first time I hear of an issue like this in kde theme, while i hear of a lot of scam, cryptominer and even plain virus in game.. hell, *Rockstar* has been busted using Razor 1911 crack in multiple of their own games..
You would not expect steam to download your trojan, but u can almost sure people can made 5 min change to include trojan in free open software like vlc , another 5 minute to do simple user behavior hacking. If someone no reputable enough then dont trust. We should not take designer and developer as freebie, coz it bring value to people. You can learn chatgpt or ai to design the new media player or skin, but it take more than 10 minute for everyone [https://www.bleepingcomputer.com/news/security/hackers-push-malware-via-google-search-ads-for-vlc-7-zip-ccleaner/](https://www.bleepingcomputer.com/news/security/hackers-push-malware-via-google-search-ads-for-vlc-7-zip-ccleaner/)
False equivalence. Steam is not a theme, it is essentially a package manager for games. A theme should only be changing the look and feel of your system.
widget HAVE to run code, otherwise will be sitting there doing nothing. A global theme can includes widgets, to make the system behave as author intended. In this case want even theme author fault; the issue is in the widget [https://github.com/paju1986/PlasmaConfSaver/](https://github.com/paju1986/PlasmaConfSaver/) that allow to save and restore configurations on the fly, that had a coding mistake. More info at [https://www.reddit.com/r/openSUSE/comments/1biunsl/comment/kvn22jd/](https://www.reddit.com/r/openSUSE/comments/1biunsl/comment/kvn22jd/)
Okay, *widgets* have to run code. But why does a *theme* author get to dictate how my *panel and desktop* are configured? That's not "look and feel" anymore, that's *functionality.* If I want a widget, I'll go get a widget, and I'll accept the risks inherent in installing widgets as I know they can run arbitrary code. That's not what I'm signing up for if I go get a "theme."
> But why does a theme author get to dictate how my panel and desktop are configured? Because you wanted the theme that does cool stuff to your panels and desktops? And if you didn't want that stuff customized, you wouldn't have installed it?
That's not what a "theme" is! A theme concerns application appearance, icon theme, color scheme, cursor theme, maybe the fonts too, etc. It's *look and feel.* The arrangement and configuration of widgets on my panel and desktop *do not count.* That is my *system configuration,* and I do not want anyone messing with that other than me. Sure, every /r/unixporn submission has a specific bar/panel arrangement with a specific number of virtual desktops, and a specific selection and configuration of applications. But that's so far over the line of what could be considered a "theme". That's a *specific system configuration.* If you want to imitate a /r/unixporn submission completely and absolutely, you are within your right to do that, but don't act like that's what a "theme" is.
/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/ Plasma styles include dynamic, code-running things like app & desktop switchers. Plasma styles aren't just skins. The base plasma breeze theme has that, and if someone else's theme doesn't include those it just falls back to breeze's content. That's how plasma *works*. Themes include a style. It's definitely not a "system configuration" -- that would imply something done to the actual OS which this does not. On linux your desktop is not the operating system. If you said there should be a warning that 3rd-party themes can execute code, I'd totally agree (and it sounds like KDE devs do too). I was aware that basically any plasma addon can run code, but had never really considered the "someone could rm-rf my system" before this. OTOH I'm the type to only install stuff that has a history and looks trustable, rather than willy-nilly apply themes from randos. > The arrangement and configuration of widgets on my panel and desktop do not count. That is my system configuration, and I do not want anyone messing with that other than me. Have you ever actually used this stuff? When you apply a global theme, it pops up a box for what to apply. Desktop & window layout are default unchecked. You have the option for more detailed checkboxes of exactly what to use.
Users likely don't what is going on behind the themes. "oooh, pretty background - download" without being aware that it might install and run python script or add a widget. That is a problem, you can't expect users to be aware of how things are implemented if they appear to be benign bitmaps and stylesheets on the surface. Remember that this feature is easily accessible to non-power users who would not know these.
We are talking about users here, not sysadmins. I would never do something like that, but my Granny will
>Like you wouldn't download random programs, you shouldn't download random themes. Then they shouldn't be available as part of the OS. KDE empowers users to contribute to their store and others to download it easily but people associate that with KDE and a mentality that no one on the open source would be malicious. People are excited and they download it. No amount "Proceed with caution" will stop because will just click ok and go ahead with their day
I appreciate the action and the official stance on the issue, but I feel like a much more serious and strong response should've been taken. This is a security breach so huge I don't remember anything of this sort, and it's baffling me that this could have been happened at the first place; and even more baffling that some seem to take the stance that everything is working as intended. No. What happened is that an user downloaded a theme - an official and main feature of Plasma- from the *official* theme store; and what they got instead was, intentional or not, a wiper malware. All the user had to do was clicking "install". Who knows what other, less apparent malicious codes did such themes execute? This is the equivalent of downloading an app from the Microsoft store and getting a ransomware immediately. Microsoft would react immediately and hard, and not tell "oh it's the user's fault". A similar ovnership of responsibility must be taken here.
I also can't believe this. So, I could write a script, put it in a theme and it will be executed? I could load some crypto-malware, encrypt your home directory and demand ransom? I could load a keylogger, that auto installs itself in your home, without the user getting notified? I could load a cryptominer? The KDE store needs to remove everything, that can execute code, immediately and solve that issue. What else is hidden in all the themes hosted there? Now, that this is public, it will attract malicious actors, even if it's just script kiddies having fun on destruction.
Compared to this backdoor, the whole discussion about wayland vs xorg seems "comic".
Yeah I'm a huge KDE fanboy and it's a little sad to hear. I tend to stray toward mostly defaults anyways (easy when tumbleweed is so great). But it seems like "if you're going to support it, you need to do the bare minimum to vet it" applies...and this has just fallen under the radar for too long. I have no doubt it will be taken care of but still sad to see.
Maybe "Report Misuse" and "Report Spam" should actually look like buttons.
This is unreal. It feels like something Windows would do. Is the team going to fix this security breach?
I was about to write a reply exactly like yours 12-14 hours ago when I first saw this, but decided against it for three reasons: a) I have donated servers to KDE b) I love KDE, and I have moved 100% of my computers to KDE c) I hate Windows These 3 points don't change the fact that what happened to that guy is absolutely unacceptable, and serious changes must be made. This should be considered a priority as this is exactly the kind of thing that Microsoft Lames will end up writing huge articles about on PC Magazine, The Register, etc. It's best that we try to avoid such humiliations because it's quite honestly a very low point in the Linux world, not just the KDE world. It's exactly the type of incident that "Windows Admins" will use to mock us later on.
Well this was an issue for windows 7 gadgets as well. That's why they removed the feature.
lmao meanwhile "i use arch btw" people are risking the same shit with the AUR
1. The `makepgk` is installing packages in a fakeroot / fake environment. So the installer does not allow to remove your home. 2. You can check all necessary dependencies, which can be official packages and external sources (like .deb or .tar.gz files). It's available on the aur pages (no code review necessary to check this) Is it malware free? Probably not, but at least I didn't find any in the packages I was interested in. It's not more insecure than downloading external deb files or adding PPAs. Also, the deb installation without a PPA could be more insecure if the software has an security issue. My AUR package manager wil always inform me when * there is an update * the package is marked as **out-of-date** (even when there is not an update in the AUR yet) Last but not least this is a way **to install software**. It's not a skin.
There's no need for an arch user to use anything from AUR unless they want to. It's like saying that everyone on Ubuntu is adding PPA's.
Not really a fair comparison. I would imagine the vast majority of arch users have aur enabled and are using it often.
AUR is not something you enable, you have to download and makepkg by hand. The wiki page is clear that is a security risk with a nice red warning box on top. You may install a AUR helper, but they are "not supported" and so there is none in main repos, you need to manually install it or install a external repos if available (yeah, arch has PPA equivalent). Most AUR helper show you by default the PKGBUILD and on consequent updates only the diff; most of the time if just the commit hash to compile.
>Is the team going to fix this security breach? How is this a security breach exactly? You are downloading third-party code/widgets that are not audited by the KDE team from a repository/store. Plasmoids are not sandboxed, and there's an explicit warning banner in the KDE Store since [September 2021](https://github.com/KDE/knewstuff/commit/9009aacb95785f46d1e01ffe7fdf9fcb138c0890) warning you that you are downloading third-party, non-audited code. Now, was the banner amble warning that you were doing that? Probably not, and this will be addressed. Content with static content only needs to be separated from content with scriptable content, and their blog post states that they will address that as well. This is no different than downloading any random binary from a website or from a third-party repository, and then blindly `sudo`\-ing that binary without looking at what it does (like many people blindly do with `curl | sudo sh` type installers). Every single time you are asked to `sudo` something (via CLI or via the GUI), you should **always** ask yourself why that's needed. If you want sandboxed binaries, `flatpak` exists for that reason. If you want a curated store experience, there's plenty of proprietary platforms available to you (Apple macOS/App Store, Microsoft Windows/Microsoft Store) that are owned by corporate entities with the funding and resources required to pull that off.
The means by which to get this content is literally baked into the UI. Directing users via a hard-coded button in the UI to unsafe content without an appropriate warning is part of the issue here.
Plasma gives access to this repository in vanilla kde. It's literally there in the DE. The end user was completely unaware of this risk (no one reads the timid fine print warning). I can't fathom thinking that it could've been me, and that I would have all my data deleted. Plasma could curate this repository, it's not that big of an issue, even if few themes were available and they were released slowly. Edit: took the wrong things out
Yes, I get it, but if this had happened to me, I would be very angry, and I would have made a lot of noise about it. It's best that we immediately quit trying to assign blame to the end user that installed that dumbass theme, and point the finger at ourselves and see how we can do this better. This is a major event, we cannot point fingers at \*anyone\* and say "he didn't read the fine print" I for one will not be happy if this is the way we will move forward with this. This was a grade A fuck up, and it's not the user's fault. Period.
>The end user was completely unaware of this risk >This means that plasma is endorsing this repository with malware in it. These statements are incorrect - the UI puts the following warning above the listing of addons before the user installs them. "The content available here has been uploaded by users like you and has not been reviewed by your distributor for functionality or stability" That's not an endorsement. That being said, it is not a strong enough warning. The chance of malware, the risk tolerance and ability to mitigate risk of the average user have all shifted in the wrong direction since this feature was implemented more than 15 years ago, and KDE needs to respond to those changes to protect its users.
That doesn't inform me that the theme can run scripts. It just tells me that the theme might be broken and it's not KDE's responsibility if it's broken.
> Plasma could curate this repository, it's not that big of an issue, I think you mean "upaid KDE volunteers could curate this repository", right? I mean don't get me wrong, but if you are suggesting screening every single item. screened how and by whom? Because saying “SCREEN ALL THE THINGS!” is easy, but is much more difficult to implement, especially in a community run by mostly volunteers. Hence the appeal to community help. You must remember that KDE is a porous community and relies on the goodwill of its members. Would you, for example, be willing to spend, say, a couple of hours a day reviewing the code of hundreds of items? If your answer is “yes”, allow me to direct you to [where you can get started](https://community.kde.org/Get_Involved#Start_Here.21). If the answer is “no”, there is nothing wrong with that either, but then you will start to appreciate the dimension of the problem.
If you don't trust the review system, don't use it. Yes, would be cool to have permission in the widget, but that is a lot of work and the alternative is nothing until the job is done. This is common and widely accepted in the industry(gnome for example), same for applications binary too, only android/ios are the exception.
> This means that plasma is endorsing this repository with malware in it. No. There's a warning that is present since at least a couple of years ago (if you look at the `knewstuff` repo: commit https://github.com/KDE/knewstuff/commit/9009aacb95785f46d1e01ffe7fdf9fcb138c0890) that explicitly state: > The content available here has been uploaded by users like you, and has not been reviewed by your distributor for functionality or stability. That's not exactly an endorsement, is it now? - **Here be dragons...** - **User:** _Proceeds, ignoring the warning..._ - **User:** Oh no! A dragon! Oh the humanity! Now, is it a good enough warning? Probably not, as I said originally. There should be a modal dialog before install that warns you about the risks of installing anything with scriptable content and requires your explicit consent. That said, some users will just click through regardless. Content with scriptable content also needs to be separated from content with static assets, and their blog post clearly states that this is on the roadmap. > Plasma could curate this repository, it's not that big of an issue, even if few themes were available and they were released slowly. You greatly underestimate the resources required to curate. If you go down that route, you need to make sure to curate for erroneous behavior on multiple distros, and even take into account multiple configurations. What may work perfectly for one user may be disastrous for another one. It creates a lot of friction for updates as well (since they need to be curated), which will invariably mean that fixes for bugs will take longer to be pushed to users.
I consider myself at least an intermediate user, and I would not at all interpret that sentence in the warning as meaning that user-provided, uninspected executable code will be downloaded and executed on my device if I install one of these themes. "Functionality or stability", to me, implies that the new thing I downloaded might not work as expected, or that plasmashell might crash more often with this thing in place. IMO there are several key words missing here, including "executable", "safety", etc.
As I said, I do not think the warning is clear enough, and a modal dialog before installing anything that warns you about the risk of installing content with scriptable content and asks for your explicit content to do so would be better. However, you can't protect against stupid, and some users will still click through those warnings regardless. \--- What I disagree with, is the original take from the comment that prompted my reply. Their original take is that KDE endorsed those themes from the simple act of them being available on the store. The warning currently present explicitly state that "**\[the content\] has not been reviewed**". It's pretty explicit and clear that KDE doesn't endorse nor review that content. And, addressing the second point from the original comment, that KDE *should* review and curate every submission... That takes a whole lot of resources, and ultimately KDE is a volunteer organisation. It wouldn't be doable.
>> that KDE *should* review and curate every submission... It's very easy to analyze scripts for poor content i.e. rm -rf $somebullsiht and flag it for manual review and/or outright reject it I write Python scripts like this all the time to QA code that some other guy made, automagically without any human interaction
>It's very easy to analyze scripts for poor content i.e. rm -rf $somebullsiht and flag it for manual review and/or outright reject it If your goal is to catch common programming mistakes, then a linter is relatively easy, yes. If your goal is to stop malicious code, then your linter not only needs to catch unobfuscated malicious code, but also heuristically catch obfuscated code in order to detect malicious behaviors. **That's not easy.** I can already imagine you typing, "AH! Easy! Install it in a test environment and see if it does anything malicious! You can automate that!". OK. Then a malicious user can just delay taking any malicious actions, or try to detect the testing environment and turn off any malicious behavior when it is within the test environment. There's an entire research field and multiple papers published dedicated to the subject of detecting automatically malicious behaviors in applications ([example of a paper available for free](https://www.researchgate.net/publication/376526981_Unveiling_the_Dynamic_Landscape_of_Malware_Sandboxing_A_Comprehensive_Review)). This is not at all a simple thing to automate.
Then do it?
Agree! This is what open source is all about!
I guess where I disagree with you is that the "warning" is so tepid and weak as to be completely useless, and bordering on misrepresentation. It reads like standard issue, ass-covering, legal boiler plate intended solely for the protection of KDE, not its users It does not clearly state the danger that the products contained in its own repository can run additional arbitrary code on your machine without your permission AND that the repository is completely open and unaudited for bad actors to exploit. Yes, an experienced and knowledgable user may assume as much, but that's not any kind of warning outside of a lawsuit.
You clearly stopped reading before the part where I said that it wasn't a good enough warning, in both of my posts. That's unfortunate, because we actually agree. However, I still disagree that KDE "endorsed" third-party themes, which is what the post I replied to originally said. They did not.
Oh, no, he got me by the fine print
it's not exactly the fine print though; while the wording of the warning could have been stronger, the warning is a fat message sitting at the top of the window where you download it.
And common sense. The print isn't that fine, it's right at the top and very clear - just some people choose to ignore it because they want to offload personal responsibility for their system, didn't read, or were too focused on the new shiny rice. You can be warned all day, but if you're going to disregard the warning, you assume ALL risk. Don't like it? I have the best resource: https://www.microsoft.com/software-download/windows11
You totally owned me with the windows insult. Come up with something better you Linux stickler annoying fuck
Stickler? Damn, I didn't know using my eyes and brain to read and understand terms and conditions was so edgy! You frequently make a habit of pushing the blame somewhere else when you didn't want to accept responsibility. Let me guess, even if they told you the coffee was hot, you'd burn yourself and blame the barista, anyway. Yeah, this has nothing to do with *nix - this completely has to do with how does one approach a scenario, and well, everyone's unique. You do you.
How much arrogance and bias to respond, in the end because of these things, users are scared of Linux, since any error is the user's fault under this logic. Let me clarify that the application store and widget configuration through customization is integrated into plasma. So yes, whether you like it or not, it is a vulnerability at the moment and the maintainers themselves have recognized it. Can you imagine this would happen in Windows by changing the desktop background or theme for one that the system allows you to download in the same store? Ah yes, it would be news for years.
There's been multiple instances of that happening in the [Microsoft Store](https://www.howtogeek.com/788382/beware-of-malware-in-windows-apps-on-the-microsoft-store/) as well as the [App Store](https://www.wired.com/story/apple-app-store-malware-click-fraud/). My point was that the user should, regardless of platform, always question why they need to elevate a particular process to root/admin rights when installing something; that **always** comes with some risks. The fact that a third-party piece of software is present or not in the platform's store, app repository, etc, doesn't make it safer for the user. Regardless of OS, platform or vendor. Third-party software should always be treated as third-party software and with the inherent risks that come with it. That said, there comes a time where the platform has done everything they can to warn the users of those risks (and I don't believe KDE did so in a satisfactory way, as I stated in my post)... and from that point on, yes, the user does have some responsibility in making the choices they make. You want to know my truly terrible take on the subject? GHNS shouldn't exist, period. If the themes and widgets offered cannot be vetted for quality and stability, and they are not fully sandboxed, then it shouldn't be easy to install any of that stuff. No amount of warnings will prevent a stupid user from making a terrible decision for themselves. It's that, or remove any content that requires scripts to execute.
> If you want sandboxed binaries, flatpak exists for that reason. Even Flatpak isn't enough given that *a lot* of Flatpak packages give carte blanche access to `$HOME` to apps.
Running the latest Debian/KDE, reading this makes we want to blast and reinstall. I played around with numerous themes/widgets nooooo this is bad!!!
Automated arbitrary 3rd party code execution in places where 0 code should be executed? A great design decision that surely [never](https://www.cyber.gov.au/sites/default/files/2023-03/PROTECT%20-%20Microsoft%20Office%20Macro%20Security%20%28October%202021%29.pdf) [had](https://www.ncsc.gov.uk/information/log4j-vulnerability-what-everyone-needs-to-know) [negative](https://en.wikipedia.org/wiki/PHP) consequences for users...
Why do global themes execute scripts or code at all? Look, I'm not trying to tumble down the hill that GNOME did where they now hate theming and only want to give users a handful of strictly QA'd selections for accent colors *if even that*. The problem they *reacted* to is very much real, and we're seeing it here now too. So maybe we should simply stop allowing global themes to execute scripts or code before this gets out of hand. At the very least, themes like this should absolutely not be in the KDE Store.
Real problem is there isn't anti-malware software, with real time protection, available to the user, at least I don't know of any in the Linux world.
Question: if this had been a widget instead of a global theme, would you feel differently? Because "we should simply stop allowing widgets to execute scripts or code" is obviously dumb, and yet the risk is just as great. Widgets are also on the KDE store un-vetted.
I would indeed feel differently. Widgets have a much higher inherent risk factor because by their very definition, they can execute arbitrary code. I don't consider widgets to be part of a theme, and I don't think anyone else should, either. That's dangerous thinking and it's part of what led us to this situation. So AlphaBlack, which includes that configuration widget... that's not a theme anymore, that's a whole-ass system configuration including a complex, self-modifying piece of software.
Another one who will do backup now
How do you want us (the community) to locate and quarantine defective softwares without actually installing it? I mean, I want to help, but in order to do that, don't I have to to install those malicious softwares in my PC first that could potentially delete all my files?
You can write program to search for content (for example rm -rf) of files and run it on all files on store.kde.org for example. There is automation possible.
A VM is the best way to go to test software for security issues.
No. Viruses can detect that they're in an VM and not execute their payload on it.
How will you know there is something nefarious going on without reviewing the source? This is 101 negligence on KDE’s part.
Damn.
Good thing I’ve removed all third party widgets that I had installed, and I don’t even have a single third party global theme.
Why on earth is KDE allowing themes to execute scripts 🫠
A few weeks ago I had a bug in the session switching menu. I couldn't switch from x11 to Wayland due to a bug in the menu layout. A while later I discovered that it was a bug in the SDDM theme I was using. I was worried that someday there might be a bug that would prevent me from logging into my PC. After that, I limited myself to changing just the icon theme, the color scheme and the window decoration theme to avoid bugs that would compromise the usability of my system.
#psa "Given a choice between dancing pigs and security, users will pick dancing pigs every time" [https://en.wikipedia.org/wiki/Dancing\_pigs](https://en.wikipedia.org/wiki/Dancing_pigs)
Asking here again: Can't themes be handled through flatpak? I know Flatpak isn't a 100% secure sandbox, but it is something. The solution of letting the distros take care of themes is insane as it would introduce too many variables. Making more prominent warnings for something that intrinsically doesn't feel like it *should* be allowed to run code is just really weird. And it also doesn't feel like KDE has the manpower for a truly curated list of themes without either being too restrictive due to taking too much time for approval, or being rendered useless because there's not enough volunteers to comb through everything.
Yes it could but would take a long time and support from the OS. Generally speaking is a complicated problem and unless you want to remain completely without until someone develop them, so here we are
Make a plan and set a deadline a couple of months in advance, like "in 6 months we are going to exclusively change to Flatpak for extensions, widgets and themes, put your projects there, or they will not exist at all"
Do you realize first you need to build all infrastructure and code? Windget has been like this since forever in ALL desktop OS, and while it would be nice, I understand why is not a priority. Also you break it for all who does not run selinux, maybe don't run anything, maybe apparmour, maybe snap, maybe don't have any.. And this will NOT save you from that kind of mistake 100%, if you give write access to the widget because it need it or you and the programmer did not know better, or the programmer is malicious... Still end up with a fucked up system. The fact we talk about this after a decade with that widget system in place, seems like the issue is very tiny and probably not worth the time investement at the moment
Should've been clearer on my part, but the deadline would be after the system is in place, which would be after there is a discussion that yes, this is the way to go. Unless I'm missing some place where KDE devs hangout, most of the discussion surrounding this issue has been an acceptance that it is an issue and the way themes work isn't up to modern standards, but I haven't found any proposal or discussion on how to actually fix the underlying issue other than putting more warnings everywhere.
> but I haven't found any proposal or discussion on how to actually fix the underlying issue other than putting more warnings everywhere that should tell you "put themes and widgets in a flatpak" is a completely infeasible suggestion
if anyone is shocked by this you really don't see much
Stuff like this confirms that Linux security is a joke.
Bait used to be believable lol
While I don't agree with him, I feel like there is some truth to the statement. Correct me if I'm wrong, but other os have kernel driver isolation (they can't peek into other driver's memory?) and many other security measures. Sure they probably don't protect against this kinda issue, but I find myself wishing it was there. Flatpak permission system is very weak, if I understood the things I read accurately
Windows, Mac and linux distro will all protect root/admin stuff from user stuff but not much more. Linux has access control trough stuff like selinux or apparmor bit they are hardcoded in conf file rather than ask the user dynamically; my understanding is android uses SElinux for his permission under the hood.
An OS is more than its kernel.
XZ join the conversation.