Re: How do we store/install apps?

[Colin Walters <walters verbum org>]

On Sat, Oct 11, 2014, at 05:35 PM, Lennart Poettering wrote:
> I am pretty sure these two formats need to be very close to each
> other, otherwise all the stuff like signatures that checked on access
> area really hard to do.

Can you elaborate a bit on this "signature check on access"?  Is
this something like dm-verity but inside BTRFS itself?

> I mean, again, I would not isolate the problem of app images so
> much from the problem of OS images.

They are different in that the OS content has to be ultimately trusted,
whereas apps shouldn't need to be.

> You know, this is explicitly something where we shouldn't reinvent the
> wheel. It's quite frankly crazy to come up with a new serialization
> format, that contains per-file verification data, that then somehow
> can be deserialized on some destination system again back into the fs
> layer...

Hmmm.  Do you think RPM/deb are crazy?  Or just creating new ones that
aren't those?

At a practical level, having run a system that's "here's your OS as a
unit"[1] for several years now, I can say that there's a broad spectrum
here, and while the app+SDK model that's being discussed here is
potentially a good improvement, there's lots of things that aren't apps.
 Like fonts, profiling/debugging tools, kernel modules, non-default
system editors (yes, I yum install emacs-nox on my servers), PAM
modules, etc.

iOS 8 introduced sandboxed extensions, and at least some of these things
should be extensions.  Others, like kernel and PAM modules are going to
need a high level of trust.

For several of these things, the "package" model seems pretty good to
me, and I can't think what we'd gain by shipping them as btrfs images. 
You want some notion of dependencies - "is my host's glibc new enough
for this strace" etc.  For profiling/debugging, you *don't* want to
containerize.

Even for the SDK model we're discussing here, the complexity of the
package model will start to creep in - "does the GNOME runtime come with
Python"  (which one?)

[1] Well, in the case of Continuous it's a choice of two units (runtime,
or devel-debug), which helps a lot make the system more practical.