[systemsettings] [Bug 468805] Support editing XDG portals permissions of Flatpak programs
https://bugs.kde.org/show_bug.cgi?id=468805 Simon McVittie changed: What|Removed |Added CC||s...@debian.org --- Comment #2 from Simon McVittie --- [I am a Flatpak contributor, but not a regular Plasma user.] > Too bad those portals don't use the same overrides config file That's partly because the overrides for sandbox parameters (the equivalent of `flatpak override` in the CLI) are "owned" by Flatpak and are unique to Flatpak, whereas the permission store (the equivalent of `flatpak permissions` etc. in the CLI) is "owned" by xdg-desktop-portal and shared between Flatpak/Snap/anything else. This is extra-confusing because people use the word "permission" informally to describe both, but the Flatpak manual pages seem to be making a point of not using the word "permission" for the sandbox parameters. The sandbox parameter overrides are described as "overrides" because the typical use for them is to override the features for which the app author has said "this app won't work properly unless allowed to...", so they're advanced/risky/can very easily break apps. In the opposite direction, it's also very easy for configuring sandbox parameter overrides to give the app much wider access than you intended it to. It doesn't seem great that flatpak-kcm displays the sandbox parameters and encourages users to override them, but without exposing the safer and more normal-to-edit permission store settings - that seems like the wrong way round. I'd also prefer it if permission-store configuration had more emphasis (e.g. at the top), with the overrides labelled as "advanced" or similar. https://github.com/flatpak/flatpak/issues/5427 is an example of a situation where access to the permission store would have been useful. The particular permission store item that was relevant to that issue (the "run in background" permission) is available in GNOME's Settings (the equivalent of systemsettings), which intentionally *doesn't* expose the equivalent of `flatpak override`, leaving that to more advanced tools. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 461289] ApplicationLaunchJob should give each launched app its own labelled systemd-journald stream
https://bugs.kde.org/show_bug.cgi?id=461289 --- Comment #4 from Simon McVittie --- If plasmashell (and presumably other ApplicationLaunchJob users) ends up exclusively using the transient service code path, then yes that would address this request. GLib/GNOME has been trying to do something similar, but the people implementing it seem to have run into a lot of practical problems (perhaps the relevant GLib APIs expose more implementation details to the app than their KDE equivalents, making a change of implementation more likely to break things?), so we weren't able to switch over to transient services everywhere, and the stream-fd-based approach that I suggested here gave existing apps a small incremental improvement. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461289] plasmashell should give each launched app its own labelled systemd-journald stream
https://bugs.kde.org/show_bug.cgi?id=461289 --- Comment #1 from Simon McVittie --- Note that steam.sh explicitly logs its own name and pid in each message, to make its messages easier to identify/attribute, which is where the `steam.sh[12345]` in my examples comes from. If an app is writing random unattributed debug messages to stdout/stderr with no particular markers, then they'll look more like the `Installing breakpad exception handler blah blah blah` lines in my examples. The behaviour I'm asking for becomes particularly useful in this case. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461289] New: plasmashell should give each launched app its own labelled systemd-journald stream
https://bugs.kde.org/show_bug.cgi?id=461289 Bug ID: 461289 Summary: plasmashell should give each launched app its own labelled systemd-journald stream Classification: Plasma Product: plasmashell Version: 5.26.2 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: s...@collabora.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY On systems that use systemd, whenever Plasma starts an app that is not DBusActivatable, log messages in the systemd journal will "blame" `plasmashell` for its output. They should show the .desktop file name instead, so users can attribute messages to apps. STEPS TO REPRODUCE 1. journalctl -f 2. Have an app that is *not* DBusActivatable=true, and logs distinctive messages to stdout/stderr. I used Steam. 3. Launch the app from an icon on the desktop (from the application menu or an applet would probably have similar behaviour) OBSERVED RESULT Messages with plasmashell as their "syslog identifier", like this: $date $HOSTNAME plasmashell[12345]: steam.sh[12345]: running Steam on arch rolling 64-bit $date $HOSTNAME plasmashell[12345]: Installing breakpad exception handler blah blah blah EXPECTED RESULT Messages with the .desktop filename or app ID as their "syslog identifier", similar to what GNOME Shell does: $date $HOSTNAME steam.desktop[12345]: steam.sh[12345]: running Steam on ubuntu 22.04 64-bit $date $HOSTNAME steam.desktop[12345]: Installing breakpad exception handler blah blah blah SOFTWARE/OS VERSIONS Linux: Arch Linux rolling release as of 2022-11-01 KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION The easiest way to implement this is to link to libsystemd, call sd_journal_stream_fd() to open new streams, and use dup2() to make them overwrite launched apps' stdout and stderr, like dbus does: https://gitlab.freedesktop.org/dbus/dbus/-/blob/dbus-1.14.4/dbus/dbus-spawn-unix.c#L1392 If linking to libsystemd is undesirable, it is fairly straightforward to reimplement sd_journal_stream_fd(), like GLib does: https://github.com/GNOME/glib/blob/2.74.1/gio/gio-launch-desktop.c Plasma could either do this unconditionally (like dbus does), or only when it detects that stdout/stderr are already pointing to the Journal (like GLib does, sample implementation: https://github.com/GNOME/glib/blob/2.74.1/glib/gjournal-private.c) -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 448803] New: flatpak backport is an outdated development version
https://bugs.kde.org/show_bug.cgi?id=448803 Bug ID: 448803 Summary: flatpak backport is an outdated development version Product: neon Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Packages User Edition Assignee: neon-b...@kde.org Reporter: s...@debian.org CC: j...@jriddell.org, neon-b...@kde.org, sit...@kde.org Target Milestone: --- Neon appears to be shipping Flatpak 1.11.3, which was a development release and is unsupported by upstream. It is vulnerable to at least CVE-2021-41133, CVE-2021-43860 and CVE-2022-21682. (I am not a Neon user myself, I'm basing this on https://invent.kde.org/neon/backports-focal/flatpak and https://repology.org/project/flatpak/versions) If Flatpak is sufficiently important for Neon to be backporting it, please use the latest version from a stable branch and keep it up to date. Flatpak stable branches are versioned x.y.z where y is divisible by 2 (such as 1.12.z and 1.10.z). If Neon is based on Ubuntu LTS, you might find https://launchpad.net/~flatpak/+archive/ubuntu/stable useful: it contains semi-official backports of current Flatpak to various LTS branches of Ubuntu. The 1.11.z stable branch was a series of development releases leading to the 1.12.0 stable release, and will not receive any further releases. There is no upstream security support for old development branches. -- You are receiving this mail because: You are watching all bug changes.
