[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: pgpJfVjdpVVkd.pgp
Description: OpenPGP digital signature


Reply to: