Yes, you would need a plug (hardware-observe might work by skimming what we have available),
are they flashing this at manufacturing? or is just “defaults” from the board they use? if they are flashing it it might be reasonable.
Also afaict that can in principle contain spaces or other special chars, that’s not a problem as such, but means one need to be careful with quoting for the snapctl command if the hook is a shell script.
Also if relevant ‘/’ cannot appear in a serial (or any other primary key of assertions).
no, I’m talking whether they flash the product_serial/dmi values? it’s a potentially bad idea to use something they don’t control. are we even sure it’s really unique?
This is why the initial post included: “Is this a recommended approach or is there something better?”
I would like some help/recommendations for how customers can ensure they use unique serial numbers (because there has been consideration in the past and for the future of denying serial assertions for duplicate serial numbers).
Has there been any thought to a process to ensure and advise customers on the importance and how they should generate unique serial numbers for their devices? It seems to me that this could become a hairy mess for some customers, especially if they ever let certain devices sit on a shelf disconnected for a length period of time and then bring the device back online, potentially with a duplicate serial number to an existing device.
I’m not sure why sitting on a shelf is relevant to this?
the serial needs to be unique only with brand/model, not globally
afaik the serial-vault makes an assumption that devices have a strong opinion about what their serial is, this means assuming that the brand through manufacturing sets that/makes it available on the device itself OTOH from snapd POV serial is not mandatory in a serial-request, a device can leave out setting proposed-serial
the serial-vault could also have a mode where if the device doesn’t specify one it generates a strong random one if the brand doesn’t care (which sound strange on the face of it but as everything it all depends)
I’m not sure why sitting on a shelf is relevant to this?
It’s just an example. Say a device were sitting on the shelf with a certain serial number. Because we haven’t really advised the customer on how they should go about coming up with serial numbers for their devices and the importance of each being unique to their context, it’s possible that they might give another device the same one as the device sitting on the shelf since they forgot about it for some reason. It’s just a hypothetical example, but it’s important not to do.
Another reason “sitting on a shelf” may matter is protecting today’s deployments from possible future requirements of serial number uniqueness.
The Serial Vault previously did enforce uniqueness (AIUI). This was turned off, but not definitively for all time (AIUI). If a device is sitting on a shelf today with a non-unique serial number, and later the Serial Vault turns on enforcement of uniqueness, that system will never obtain a serial assertion and will never be able to install from a secure brand store. Perhaps other currently unimagined software will (reasonably) assume that a serial number uniquely describes a device (isn’t that fundamental to the idea of a serial number?).
So today, we do not forcefully warn/advise: Ensure your serial numbers are unique! (within the project domain). I worry this can set up for problems later.
If the device service (typically the serial-vault) requires to set registration.proposed-serial to use as the “serial number” (a string, not necessarly a number) part of the identification, then this must be set to a value that is unique across all devices of the brand and model. This also cannot contain /.
The serial vault as I understand it does not now require a unique serial number. It does issue a serial assertion with the revision incremented for duplicate serial numbers. But, the SV did at one time require serial number uniqueness. I suppose it might again someday require uniqueness (non-unique serial numbers does not make much sense on the face of it.)
So the above added text does yet not seem to me to give enough advice.
On reread, I see that you are saying set it uniquely. But this follows a complex “if”. It is not clear to me that users can answer the “if” very easily.
Can we not simply say something like: Ensure the serial number is unique across brand/model…
I tried to turn the sentence(s) around, hopefully it’s clearer:
One must ensure that registration.proposed-serial is set to a value unique across all devices of the brand and model and that it does not contain a /. It is going to be used as the “serial number” (a string, not necessarily a number) part of the identification in case the device service supports setting it or requires it, as is the case with the serial-vault.
