Re: signing commits

[Colin Walters <walters verbum org>]

On Fri, 2013-08-30 at 12:29 +0200, Sjoerd Simons wrote:
>  The tricky bit here with ostree is that there are no
> guaranteed intermediary states (which i'm wondering if they maybe needed
> at some stage for production deployments, but that's for the future). 

How people will handle management of their OS versions in an OSTree
world is still somewhat of an open question.  For gnome-ostree I
obviously get out of much of the problem by not having
stable versions =)  And also by not having to deal with "real world"
stuff like you mentioned on IRC where you need to flash firmware or deal
with extraneous stuff.

Now, you can force intermediate states by cutting new major versions,
and then having an init script at the end of a version series that sets
up the next major version as the new origin.

For example:

exampleos/3/x86_64-runtime

Is version 3, and the client follows it.  At the end it contains a new
systemd unit:
/usr/lib/systemd/system/exampleos-firmware-upgrader.service
as well as:
/usr/lib/systemd/system/exampleos-switch-major-version.service

which then sets up the system to start looking for
"exampleos/4/x86_64-runtime" by editing the .origin file.

So this model is pretty much how major OS vendors tend to work; you get
large upgrades all at once.  But I think OSTree would potentially be
very helpful if you say wanted to roll out an upgrade to only a subset
of users, and have them test it with the ability to roll back.

Ubuntu just started doing phased deployments with their SRU updates,
which is looking at the problem from the "minor upgrade" side.

> In my view it's better to create the "master" repository & commit in a
> secure location (e.g. no public service, limited amoutn of users etc),
> sign it and then throw it out into the world via whatever way, which can
> be http, https, or sneaker net.

That makes sense, absolutely.  So let's proceed then with the model
where trusted keys will come with the OS, and not attempt to build in
support for anything like Ubuntu's revocation set at this time.