Lazy/fallback serial registration for classic

pedronis 2017-07-06 11:17:44 UTC #1

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.

Snapd using 100% CPU in x86 VM for 2 minutes after boot?

pedronis 2017-07-07 14:43:55 UTC #2

relatedly we merged this:

pedronis 2017-07-07 14:58:10 UTC #3

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

pedronis 2017-07-07 17:47:22 UTC #4

@niemeyer @cprov I proposed:

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.

pedronis 2017-07-26 15:13:03 UTC #5

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.

pedronis 2017-08-10 16:08:41 UTC #6

opened this to support “generic”-signed serials:

pedronis 2017-08-12 17:24:19 UTC #7

I updated:

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.

pedronis 2017-08-22 19:13:50 UTC #8

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?

niemeyer 2017-08-23 03:03:16 UTC #9

@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.

pedronis 2017-08-23 11:15:01 UTC #10

opened:

noise 2017-08-23 15:51:09 UTC #11

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.

pedronis 2017-08-23 16:06:45 UTC #12

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.

pedronis 2017-08-23 20:02:20 UTC #13

@cprov I have created

in case we need to allow more for discussion time and so cannot make 2.28.

pedronis 2017-08-23 20:12:57 UTC #14

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 )

Opt-in accepting/distribution of 'generic'-signed serials

cprov 2017-08-24 02:33:17 UTC #15

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.

jamesj 2017-08-24 10:59:36 UTC #16

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.

pedronis 2017-08-24 16:17:47 UTC #17

I applied the revert in #3794 and closed for the time being:

to concetrate on generic/generic-classic for now.

pedronis 2017-08-24 16:45:17 UTC #18

I updated

it’s ready for review, but blocked on the store functionality to get e2e testing.

pedronis 2017-08-25 18:38:23 UTC #19

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.

pedronis 2017-08-28 11:53:50 UTC #20

Functionality to sign for generic/generic-classic is now active in production in the store.

#3573 has also now grown a specific spread test.