we have discussed details and planned work at the last sprint:
there are still a couple open questions about the fallback if there’s no model (old images, non ubuntu distros, etc) at all.
1 Like
btw, we were already waiting to auto-refresh only after having (or having tried to get and failed for a while) a serial on core, so on that front just a matter of behaving similarly on classic
1 Like
https://github.com/snapcore/snapd/pull/3573
It also adds a fallback using a dummy model if there is no model/seed data at all, for example for preexisting classic systems etc.
There’s an open question/TODO at https://github.com/snapcore/snapd/pull/3573/files#diff-0b649265c21137e8fd367d4a16607a82R174 about that, whether we want actual fallback model assertions to back that.
the plan for the fallback when there is no specified model assertion (also preexisting systems) is to introduce a “generic” brand/account and have a hardcoded model and assertion in snapd like this:
brand-id: generic
model: generic-classic
classic: true
…
the store will have keys to sign serials for “generic” that will also be used to sign serials under authority “generic” for models that didn’t setup a dedicated serial vault, while preserving brand-id/model in that case.
1 Like
I updated:
https://github.com/snapcore/snapd/pull/3573
to use the generic/generic-classic fallback model assertion. Now branch is blocked on the store being actually able to sign serials for that and ‘generic’ in general.
latest consensus is that this will be an opt-in enabled by generic-serials: true in the model assertion, in which case the device will accept serials signed either by the brand or by ‘generic’ .
@niemeyer does the latter though imply for example access to a branded store, or should we keep those two kinds of serials distinct at that level?
@pedronis I think by the time a branded store is in play, the custom serial vault should be in place and able to emit serial numbers signed by the brand itself, similar to existing devices we have that are already in the wild.
This also seems less of an immediate concern, since it’s store side logic that we can tune later.
We need to further consider this as we want to ensure that all devices have a serial and device session. Having this as an opt-in means we will continue having misconfigured devices (no serial from either the store or an independent vault) running without sessions. We could block that case but need to handle existing devices in that state and provide appropriate messaging on the client end.
1 Like
Notice also that given we don’t track all model assertions, if there was a model with the flag on and then a new revision removes it, the one with the flag on can be used to get a session at a later point. Basically the store itself cannot use the flag for much, unless we switch to forcing people to submit all models to us beforehand.
@cprov I have created
https://github.com/snapcore/snapd/pull/3794
in case we need to allow more for discussion time and so cannot make 2.28.
there’s ongoing discussion that on top of asserts,overlord/devicestate: accept generic serials only if the model has generic-serials: true we should also change the registration protocol to send the model assertion as well, this would require small changes to the serial-vault as well (cc @jamesj )
Distributing the assertion to all devices complicates things unnecessarily. From the brand perspective (can this device access brand-restricted snaps?) what would be the benefits of given away assertions that cannot be fully trusted ? Either because they are simply unsafe for the brand standards or model creators didn’t fully understand the risk involved when they started.
Identifying brand: generic model: generic-classic does not offend the established trust-path in snapd (serial-signing-authority == brand-authority) and covers the vast majority of devices currently unidentified hitting the Store. The uncovered parcel would be, firstly small and strictly 3rd-party models that haven’t settled on an effective session service, which is a problem we can attack straight away, while we collect the benefits of having generic-classic identified in 2.28.
If the points above are valid, we could safely move forward granting “generic” serials for “generic” models.
2 Likes
Thanks for the heads up.
Please let @rmescandon and I know when you are clearer on what the changes to the serial-vault will be.
I applied the revert in #3794 and closed for the time being:
https://github.com/snapcore/snapd/pull/3785
to concetrate on generic/generic-classic for now.
I updated
https://github.com/snapcore/snapd/pull/3573
it’s ready for review, but blocked on the store functionality to get e2e testing.
now #3573 has also been tested with success against the functionality enabled in staging in the store.
That is not deployed yet in production though.
Functionality to sign for generic/generic-classic is now active in production in the store.
#3573 has also now grown a specific spread test.