On Tue, 21 Jun 2016 at 14:16:55 +0100, Jonathan Dowland wrote:
> I'd actually like to see a wider discussion as to the merits of snappy versus
> flatpak (and others) and the pros/cons of supporting (or otherwise) multiple
> such things or picking one (or waiting to see whether any get any kind of
> real-world traction).
(Disclosure of bias: I maintain flatpak in Debian. I think it has a
lot of potential, and so does my employer Collabora.)
We've had 0install and Limba for years, so I don't think there's any
harm in a "collect them all!" approach. Anything that is RC-buggy
or that isn't considered to be supportable in stable (whether by its
maintainer or the release team) can be removed around freeze time.
For me, the big factor that pushes Flatpak and Snappy ahead of the older
versions of this concept is that sandboxing the apps is explicitly a
goal. They take different approaches: Flatpak uses containerization
features (namespaces), while Snappy uses the AppArmor LSM. Either way,
the aim is to move their apps out of the trusted computing base,
which would be a big step forward.
In practice the sandbox is leaky in both cases if an attacker can
achieve arbitrary code execution, because both normally pass X11 through;
when Wayland and/or Mir finally become widely enough available for app
publishers to rely on them, they'll address that concern. If an exploit
in a sandboxed app is limited to arbitrary file reading or writing (as
opposed to arbitrary code execution and IPC), my understanding is that
Flatpak's sandboxing should already be enough to protect you, although
there might still be gaps for some specific files.
If I understand correctly, on distributions that don't normally enable
AppArmor (everything major except Ubuntu and SuSE?), none of Snappy's
sandboxing is enforced. This seems like a very significant limitation,
and I'm not sure why Canonical consider this to be a good time to promote
Snappy as a cross-platform solution despite that gap. I would encourage
the Snappy developers to look into using bubblewrap (which is Flatpak's
sandboxing/containerization helper, spun off into a separate project
so it can be shared by multiple API-users) or some similar namespacing
approach.
One of the things I've been trying to encourage in upstream Flatpak is
making sure it can coexist with its competitors. The Flatpak command-line
interface and library are really designed to be "mechanism not policy",
with something like GNOME Software providing UI and letting the user
choose trusted sources. GNOME Software is the first example I know of for
a UI that supports installing Flatpak packages, although the version
in Debian doesn't have that enabled yet; its plugin architecture
also supports distro (deb/RPM) packages, Limba packages and even Steam
games in the same UI, which is encouraging.
I'm not sure whether we'll end up with end-user-facing support for
Flatpak in Debian 9. If it seems suitably mature by then, we can
enable it in GNOME Software and any similar GUIs that support it;
if not, I think disabling the UIs and shipping it as a
command-line-only, "for advanced users" package that isn't
installed by default seems like a reasonable approach.
On a purely non-technical level, Snappy's asymmetric CLA makes
me wary about contributing to it or encouraging its adoption. I
can't help thinking we've been here before with Upstart/systemd,
OpenOffice.org/LibreOffice and Mir/Wayland.
S
