Allow models to include kernel and gadget snaps from other brands

[Celso Providelo]

Snapd currently only allows models to include kernel and gadget snaps from the same signing brand-id.

This makes sense in the context of the global store, preventing confusion between model owners and kernel+gadget (device authentication) providers. At the end of the day kernel+gadget are specific to HW.

However we are seeing real use-cases for OEMs (white-label) hardware providers who want to sell their equipment with Ubuntu Core support, i.e. with official kernel and gadget snaps maintained exclusively in their own store and available for inclusion into any buyer's store.

It seems highly desirable for all parts involved to benefit of the existing Snap store ecosystem, let's say, Brand Acme buys a batch of gateways from Brand Connectrix along with the "rights" to deploy the corresponding kernel and gadget from the Connectrix store allowing Acme to have complete authority on those devices.

Relaxing the check is obviously possible, the question is how can we limit this relationship, between snap consumers and providers. For example, Connectrix sells 1000 gateways to Acme and presumably the right to deploy up to 1000 instances (entitlement ?), or in a more practical front, by reusing the Connectrix's gadget, Acme devices will continue to be authenticated by Connectrix authority (serial assertion) and thus unable to access snaps in the Acme store.

This scenario has clear intersection with the "remodeling" effort currently in progress and its natural follow up to support transitions between brands.

[Samuele Pedroni (pedronis)]

We have 3 relevant voices here:

U the user of the device (assuming they have access)
B the brand of the device
P the publisher of the kernel or gadget

with the current rule we enforce B == P unless P is Canonical

* in general regarding U our first goal is avoiding them installing somehow an inappropriate kernel for the device, there are development scenarios and cases where B would be ok for them to pick a kernel among many but they are not immediate use cases

* B expresses his voice by referring to a kernel or gadget in the model, so that's covered already

* P has no voice so far, except the implicit rule basically says canonical is happy to have our kernel used anywhere (so far). Among the mechanisms we sketched so far something like a model (or brand?) entitlement from P to B model(s) would let P express their voice

* a different point of view is that would be a store access from B models to a store with P kernel or gadget, it's a fuzzier and more dynamic state of things, and right now that state is only available when online

[Zygmunt Krynicki (zyga)]

This is a new feature request and it is being discussed by appropriate people. I'm marking it as a wishlist item since it is a new feature. Please feel free to raise the importance if this is affecting you seriously.