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
