As a very brief introduction to the topic, an assertion in the snap world is a simple signed text document which conveys the opinion of some party about a given subject. We call that signer the authority of the assertion, and this could be a snap publisher, an image publisher, or anyone else that wants to participate in the conversation.
The model assertion in snapd, for example, is a structured text file signed by the image publisher. It’s called model assertion rather than image assertion because the model states facts which will often be specific to a particular kind of device, such as the model of a laptop, or drone.
That specific kind of assertion was only taken into account for pure snapd images originally (those where snapd manages the entire root filesystem as a snap), but since then we have slowly been generalizing the feature so that they will sit correctly in a classic system as well. The benefit here is that the model can state a few different things, such as which snaps are supposed to come pre-installed, and also which gadget snap should be used on that system. That latter one allows customizing the image further, such as providing hooks that respond to given events, or establishing custom configuration options for the stock snaps defined in the model, or even establishing interface connections which would usually be disconnected but that this one image needs them connected (that’s coming soon).
So, this post is just a seed to open up the conversation about this topic and serve as reference and documentation.
For now, I’ll just write down a few questions I’ve heard on the topic. Later we can expand it to be more prosaic:
Should I use “classic” as a model name?
No, that’s not a good idea, because it doesn’t convey any information at all about what this model is. A better name would be opensuse-linode-amd64 for example, for an OpenSUSE image that’s customized to run on an amd64 machine in Linode.
Note that most assertions may be updated over time, but once a model assertion is baked into an image, the model name in it is part of its primary key, so only new revisions of this particular model will be delivered into that image. If one model is used for every image, updating one assertion updates every running image.
Should I encourage everybody to use my model unchanged with their own images?
That’s probably not a good idea either. Although the checks are not all in place today, snapd performs several kinds of cross checking to ensure system self-consistency and safety and over time will perform more of those to protect the machine. For example, custom kernels must be signed by the same authority that signed the model, because that asserts responsibility over creation and updates of what would otherwise be an unknown kernel.