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
