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. _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
