Re: How do we store/install apps?

[Lennart Poettering <mztabzr 0pointer de>]

On Mon, 13.10.14 18:37, Colin Walters (walters verbum org) wrote:

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

Yes. Correctly. The hash-tree stuff, that is verified on access.

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

Well, I disagree. In today's world you want the fully verifiable
OS. You want it in the data center, you want it on end user
devices. This is what ChromeOS does, and is what we are seeing is
being done for CoreOS, for Android, for iOS and MacOS too. 

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

Hmm? I am basically saying that we should try to stick to things such
as btrfs send/recv to distribute deltas, since it already exists for
precisely this purpose and is used outside of our immediate usecase.

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

Yeah, a scheme of OS extensions makes sense. I didn't list them in my
blog story though because they are a bit more messy. I am pretty sure
we should support extensions for the OS itself only without
sandbox. Afterall it's really the OS that you extend there.

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

Well, the "framework" concept I suggested should really include gcc,
gdb, strace and all those things. It should be the real deal, that
allows you to develop stuff.

And I am pretty sure an extra editor should be packaged as app, and
not be part of the OS itself. However it should have a less strict
sandbox so that it can be used to edit writable files everywhere in
the fs.

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

This is up to GNOME to decide really. GNOME should ship a Python
version it feels comfortable to support. 

Lennart

-- 
Lennart Poettering, Red Hat