Meeting on store content distribution after Monday's Plasma meeting

[Carl Schwan]

On Thursday, March 21, 2024 3:46:47 PM CET Nate Graham wrote:
> 
> For the purpose of stimulating ideas and discussion in the meeting, let
> me note down a few complementary routes that I could see us going down:
> 
> # Moderation
> have trusted experts filter out dangerous or broken content so it
> doesn't get distributed to unsuspecting users in the first place.
> Example: the distro packaging model.
> 
> This would have to be done on pling.com. It would look like a
> fundamentally different upload process involving new content being
> checked automatically against templates of allowed files and folder
> structures, and humans manually reviewing and verifying everything.
> **Feasible now, but doesn't scale well, or at all (as evidenced by the
> lack of anyone volunteering to do it during the time it's been known
> that this was an issue)**

It's a bit of a chicken and egg problem. Currently there is no way to review 
new package being uploaded before they are published, so no one can do it even 
if they wanted. Another issue is that the package is directly uploaded by the 
user, instead of doing it a bit like distros and requiring to provide an url + 
checksum which would at least ensure that the content in store is the same as 
in the linked repository.

Flathub has a manual review process to submit a new package and they are 
currently improving it so that updating the permissions also require another 
manual review (in addition to be sandboxed). I think not even from a security 
point of view, but having some quality requirement before allowing users to 
upload a package would be a good thing.

This whole discussion make me want to restart my work on an alternative store 
implementation ;)

> # Restriction
> Limit the damage that dangerous or broken content on the user's system
> can cause. Here are some examples of what could be done on the KDE side:
> 
> 1. Only allow the executable data engine to be run by widgets, not any
> other kind of QML code (e.g. logout greeters and OSDs). **Probably
> feasible**

I'm not sure it is feasible to exclude a specific data engine for non-widgets 
QML but it is also not the solution for this particular problem. If I 
understood correctly, the script was executed in this particular case by a 
widget. One thing that make plasma widgets powerful is the capability to run 
scripts, so instead of disallowing executing scripts completely, I think a 
plasmoid should declare in their metadata the script they can execute (with a 
list of regex) and if the widget tries to execute a script outside of the 
things they are allowed to, the script is simply not executed and a warning 
could be displayed. This also makes it easier for a manual review to know what 
type of script the widget will execute.

We should also do the same for HTTP request.

> 2. Because it's so security-sensitive, prevent Plasma from loading
> custom lockscreen QML code in Global Themes (as we did for custom
> KRunner QML in Plasma 5 times). **Feasible but would disable themed
> lockscreens until we roll out a new no-code theming engine**

We already have a no-code theming engine for the lockscreen which is the 
plasma style. The more advanced QML style is only really helpful when doing 
custom layouts (e.g. plasma mobile) which a no-code theming engine won't be 
able to do. The custom layout thing is only really useful for plasma mobile 
and custom shells and the idea from this MR to move this to the shell package 
makes sense to me.
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/482

> 3. Run all 3rd-party widgets in a Flatpak-like sandboxed process and
> make them use portals to interact with various parts the system **Maybe
> feasible and would only break some widgets?**

This is unfortunately from a performance point of view not possible. Maybe we 
could run instead only run the Script DataEngine in a sandboxed container? So 
instead of runing QProcess directly, do more fancy stuff with bubblewrap.

> 3. Change the `ConfigFile()` feature of Plasma scripting so that it's
> only able to touch an allow-listed set of config files in Plasma and
> maybe other KDE software, not arbitrary ones on the system. **Maybe
> feasible and would only break some Global Themes**

I don't think this would make a difference as soon as the user is able to 
inject a QML file it's game over.

> 4. Remove or disable the executable data engine and force widgets to use
> Plasma and KWin scripting APIs, or else prompt for confirmation every
> time it's used. **Probably unfeasible as it would break most 3rd-party
> widgets and/or be super annoying to users**
>
> 
> 
> # Segregation
> This would also be done on the KDE side and look like any of these:
> 
> 1. Show a much more scary warning for content that can run arbitrary
> code, such as QML Widgets and Dolphin servicemenu entries. **Feasible now**

We also need to keep in mind that saying to the user: "don't use it, it's 
dangerous" while also keeping the feature itself enabled and only one click 
away from Discover and the system settings is a confusing message to tell to 
the user. Probably would be a good idea to combine this point with the review 
process and adapt the message on a per package module by saying for example: 
"This is user provided content but it has been reviewed by X trusted KDE 
developers X time ago."

> 2. Show a less scary warning for content that can't. **Feasible now**
> 3. When Global Themes include widgets, notify the user about this and
> show the "can run arbitrary code" scary warning. Prompt them to either
> acknowledge the potential danger and explicitly proceed, or filter out
> the widgets. **Feasible now**
> 
> 
> 
> # Remove unneeded themability
> An example is splash screens, 99.99% of which could be a static or
> animated image, or maybe one overlaid on top of a fixed background. If
> we let the user choose their own image, then we could remove splash
> screen themability entirely. We could also just leave SDDM visible until
> Plasma is ready and do an animated transition there, deleting the
> concept of the Plasma splash screen.
> 
> 
> 
> Nate