RE: RE: appimage, snap, flatpak, backport, when to use which?
Just to say Thank You to ALL of you answering on my question, your information was very helpful to me!
Especially helpful was your reminder, that "if you upgrade a depended-on package like a library from backports, everything on the system uses that backport". I wasn't really aware of a backport installation always being a system wide change, and not a selectable alternative only. Thanks for this important clarification!
Best regards, Marco.
-----Original Message-----
From: Neil Williams [mailto:codehelp@debian.org]
Sent: Wednesday, July 18, 2018 11:46 AM
To: Simon McVittie
Cc: debian-backports@lists.debian.org
Subject: Re: appimage, snap, flatpak, backport, when to use which?
On Wed, 18 Jul 2018 10:16:31 +0100
Simon McVittie <smcv@debian.org> wrote:
> On Tue, 17 Jul 2018 at 17:25:40 +0000, Marco Moller wrote:
> > Is it because backports are centrally installed for all users, while
> > the other options are to be duplicated for each single user?
>
> Flatpak can work either way (per-user in ~/.local/share/flatpak or
> system-wide in /var/lib/flatpak). Only an appropriately privileged
> user[1] can install or remove an app or runtime system-wide; after
> it's been installed, by default any user can upgrade it to its latest
> version[2].
Is there a mailing list or similar for discussion of Flatpak? Are there equivalent places for appimage or snap?
> I think Snap is always system-wide and AppImage is always per-user,
> although I don't know for sure (I don't use those myself).
>
> One major difference between "app"-oriented systems (Appimage, Snap,
> Flatpak) and Debian backports is that if you upgrade a depended-on
> package like a library from backports, everything on the system uses
> that backport. For instance, if you are using a GNOME-ish desktop and
> you install GLib from backports because some GNOME app in backports
> depends on it, the backported GLib will also be used by components in
> the base OS like gdm, GNOME Shell and NetworkManager, with a higher
> risk of regressions than a pure stable system - only one copy of GLib
> can be the first in the system-wide library search path. This makes
> maintainers reluctant to backport lower-level libraries like GLib and
> GTK+, which in turn limits the apps that can be backported - to
> backport Flatpak from stretch to jessie, I had to apply some
> significant patches to make it work with an old version of GLib.
All calls using one version of a key library (as with backports) does make it easier to deliver security updates to all reverse dependencies of that library. How does Flatpak deal with that?
> In the "app"-oriented systems, dependency libraries are either bundled
> with the app, or (for systems that support it, like Flatpak) taken
> from a "runtime" that exists in parallel with the base OS. This means
> the app is free to use a newer version of a library like GLib or
> GTK+, while leaving components of the base OS using the older branch
> that we have tested them against.
The admin has to take this into account and understand that just because the app provided by Flatpak has had a security fix applied in a newer version of the library, anything else on the system using the same library outside that app needs a *separate* fix.
> Some of the "app" systems (Flatpak, Snap on systems with AppArmor
> (only partial coverage unless using Ubuntu's patched kernel), and
> Appimage when combined with Firejail) are also designed to sandbox
> apps so that bugs, security flaws or malicious code in the app can be
> mitigated.
sandboxing protects the rest of the system after an attempt is made to exploit a security bug but attempting to exploit the bug still has implications, so the bug itself still needs to be fixed. A common worry with app-oriented installations is that the security of the components within the app is dependent on the maintenance of the app and fixes for the same bug in the same library delivered in one app do not necessarily get fixed in other apps using exactly the same library.
> This is not very effective on current Debian stable due to the need to
> use X11, but should be a better security boundary in buster, where at
> least GNOME (and possibly other desktops) uses Wayland by default.
>
> smcv
>
> [1] Debian default: a member of the sudo group. This is configurable
> by adding polkit (policykit-1) configuration files.
> [2] This is also configurable by adding polkit configuration files.
There's no absolute answer here - there are different solutions, each has their own benefits and limitations and a lot will depend on precisely how each machine is configured and what packages are available at which versions using which method.
--
Neil Williams
home@codehelp.co.uk
Reply to: