Re: appimage, snap, flatpak, backport, when to use which?

[Simon McVittie <smcv@debian.org>]

On Wed, 18 Jul 2018 at 10:46:17 +0100, Neil Williams wrote:
> 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.

Yes, absolutely - use the right tool for the job. One of the things I
find encouraging about Flatpak is that it has a definite goal (modular,
Android-like "apps" for leaf GUI packages) and its maintainer is
willing to put other classes of "package" outside its scope, avoiding
the tendency towards scope creep. For instance, depended-on components,
desktop environment infrastructure like gnome-settings-daemon, and
non-GUI leaf packages are not what Flatpak is designed for.

If you *want* base OS infrastructure to be making use of a
newer-than-stable component, perhaps best exemplified by backports of
things like the kernel and systemd, then backports are the right tool
and Flatpak is very much not.

> Is there a mailing list or similar for discussion of Flatpak? Are there
> equivalent places for appimage or snap?

Flatpak has a mailing list,
https://lists.freedesktop.org/mailman/listinfo/flatpak

Appimage and Snap seem to only have web forums,
https://discourse.appimage.org/ and https://forum.snapcraft.io/
(but perhaps someone who knows them better can point to a mailing list).

> 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?

Key libraries tend to be provided by *runtimes*, which are collections of
libraries, available in whatever branches their publisher wants them to
be (for example there's a GNOME runtime with a selection of common GNOME,
GNOME-adjacent and lower-level libraries, and a new branch of that runtime
for each of their 6-month release cycles). Updating a runtime updates
the libraries for all apps that use it, and the runtime publisher is
responsible for choosing and following an update policy for each library
(for instance "track the versions that correspond to GNOME 3.28", "track
the versions from Debian 9 including security updates", or even "build
the latest git snapshots of everything from upstream source" if they are
that way inclined). App publishers choose which runtime their app will
run on, so they can switch between branches at their own pace (subject
to the constraint that if they don't move away from a branch before its
maintainer stops supporting it, they will no longer get security updates).

Rarer or more specialized libraries, or libraries that need to be very
new because they are tightly coupled to the app, are bundled with the
app itself. It's up to the app publisher to keep those up to date by
rebuilding the app with newer dependencies; they are not shared at
all. An app publisher can reduce the number of libraries they need to
bundle (possibly to 0) by choosing to base it on a "larger" runtime with
more libraries, if there is one (for instance the GNOME and KDE runtimes
are both supersets of a freedesktop.org base runtime, so an app that is
based on the freedesktop.org runtime and uses some GNOME libraries can
reduce how much it needs to bundle by switching to the GNOME runtime).

For more details please see the Flatpak documentation, or my recorded
talks from Debconf 2017 and FOSDEM 2018.

> 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.

Yes. Having to update more than one thing for the same CVE is the price
you have to pay for providing one version of a library to an app, and
a different version to a different app or to the base OS.

If updating libraries within a compatible, non-parallel-installable
release series (for example OpenSSL 1.0.x, GLib 2.x, GTK+ 3.x or Qt
5.x) never caused regressions, then perhaps we'd all be happily running
rolling releases like Debian unstable or Arch Linux; but the fact that
we (and many others) make stable releases indicates that some people do
value holding back versions to avoid regressions. Backports partially
undo that, which is sometimes the best trade-off, but sometimes not.

If you want to see what this could look like in practice, I'd encourage
you to install testing/unstable with GNOME 3 in a VM or on spare hardware,
install some Flatpak apps from Flathub, wait a few days or weeks, and
check for updates in the GNOME Software app. If you've chosen apps that
use different runtimes or different branches, you'll see that each app
and each runtime branch is presented as a separate update in the GNOME
Software UI, with "Update all" as a recommended action.

> 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.

Yes, this is one of the things that worries me about Appimage. Flatpak's
use of runtimes partially addresses this, by providing a middle ground
between "everyone shares one library, regressions and behaviour changes
are potentially Very Bad" (traditional OSs) and "bundle every library
you need, but then you need to security-support them" (Appimage).
My understanding is that Snap has something similar to Flatpak runtimes
but can also be used in an AppImage-like mode (and I don't know the
right Snap jargon term for its equivalent of runtimes).

    smcv