WARNING: Global themes and widgets created by 3rd party developers for Plasma can and will run arbitrary code. You are encouraged to exercise extreme caution when using these products.
On the one hand, if any commercial store put out a statement like this and did no vetting of submitted applications people would (rightly) be up in arms. But on the other, this is pretty much the standard with FOSS, right? Unless you’re paying for a supported commercial license from someone like Red Hat, everything is as-is, without warranty, caveat emptor. The power of open source is that anyone can review the code and look for problems or malicious behavior, but also (especially with smaller projects) there’s no guarantee that anyone else has looked at the code. So is it a best practice with Linux and FOSS to run a system backup before installing any software or update? I mean I guess that’s technically true for any OS, but especially for open source?
Users are probably aware of that with most software. But for something called a “theme”, we’re used to expecting it to be a bunch of non-executable resources. I’m sure I wasn’t the only one who gave it no thought and made this assumption, since it applies almost everywhere else we see themes.
Yeah 100%.
They should be given a more threatening name.Maybe the word “global” is supposed to invoke fear (maybe it does for people who review shonky c++ code a lot).
But I don’t think that is so for most people.
Better to call them “High risk unofficial theme” or something to prompt people to read the small print.
In my mind, it’s more like a library of scripts. Scripts are powerful and could potentially do anything, and it would be wise to not run these scripts arbitrarily without reviewing them first or having some other trust basis you can rely upon.
For example, I don’t think you’re expected to review all open source software on your system. It’s much easier to instead trust a group of people with high visibility, such as the core Debian developers, and proceed to exercise graduated caution according to the likelihood that the code has been reviewed. You probably don’t need to review the Linux kernel. When it comes to random widgets and themes off the internet, it’s easy to encounter code that has never been reviewed.
I think there is such a thing as a risk tolerance. You can’t build a completely trust-free computer. For practical and economic reasons, you’re going to have to trust somebody. I think the optimal strategy is to be smart about who you’re trusting and where you’re focusing your limited resources to review. Popular Debian packages? Probably safe. Widget by person you’ve never heard of that nobody else uses? Probably risky.
If this makes you feel uncomfortable, I suggest that a person takes a few moments to review their threat model. What kinds of attacks are you worried about? What costs are you willing to pay to mitigate these attacks?
I would just be mindful of independently generated content. A backup will not help you if your computer is in a bot net
Why would a backup not help with a bot net? Shouldn’t rolling the computer back to its state before installing the malware remove it? (This is a genuine question; I’ve had very little exposure to actually using Linux but am interested and will probably install it on a machine someday)
Botnets work as background malware, most people never realize they’re infected, as opposed to in your face malware like ransomware.
Backups are only relevant for malware if you can pinpoint when the malware was installed and the backups aren’t compromised.You would need to know your infected
So is it a best practice with Linux and FOSS to run a system backup before installing any software or update? I mean I guess that’s technically true for any OS, but especially for open source?
Being opensource doesn’t make backups an extra special requirement. Backups should be considered a compulsory, non-optional thing these days, regardless of your choice of OS. I mean, your device could crash or fail, get stolen, get damaged, get hit by crypto - anything is possible. Being opensource or not makes little difference to the question “is it best practice to backup”.
As a big fan of KDE Plasma, I feel like this is a huge blunder on their side, and am rather disappointed. I do hope they can move forward learning from this.
I wonder if it applies to GNOME extensions
Haven’t heard anything like that. Doesn’t mean for sure it’s not there, but if it is we would’ve heard of it, considering how popular GNOME is.
If KDE can have it gnome certainly can
In theory: yes.
In practice: depends on how things are implemented
The jump from v5 to v6 is quite a big one. It is understandable things can fall thru the cracks.
Nevertheless, allowing themes (especially of unknown source) to execute arbitrary code is never a good idea.
GNOME extensions aren’t themes, though. They’re executable by design and intuition; they’re basically applets.
However, GNOME does have themes (hidden in the GNOME-Tweaks app) and AFAIK they’re purely CSS.
Well then I wonder if a gnome extension could take over your machine and attack other machines on the network
The same risks apply to any software proprietary or open source which is why Microsoft have the following in their licence agreement:
- DISCLAIMER OF WARRANTY.The software is licensed “as-is.” You bear the risk of using it. Microsoft gives no express warranties, guarantees or conditions. You may have additional consumer rights under your local laws which this agreement cannot change. To the extent permitted under your local laws, Microsoft excludes the implied warranties of merchantability, fitness for a particular purpose and non-infringement. FOR AUSTRALIA ONLY: You have statutory guarantees under the Australian Consumer Law and nothing in these terms is intended to affect those rights.
LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. You can recover from Microsoft and its suppliers only direct damages up to U.S. $5.00. You can’t recover any other damages, including consequential, lost profits, special, indirect or incidental damages.
Knowing that and knowing that themes can have code is two different things though. I wasn’t particularly surprised as I thought (maybe wrongly) that global themes just installed all the other bits which would require code.
KDE can’t get away with “user at risk” for a DE designed for general purpose users. That means users who aren’t technically minded or linux experts. Maybe hyprland and i3 can tell users to RTFM but an embedded store distributed with ALL KDE versions should have some sensible design decisions such as “maybe dont allow arbitrary JS execution as root within a feature people don’t expect to be doing more than changing the background pic and some fonts”
