Skip to content

record caboose SIGN value in inventory #7914

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
5 tasks done
davepacheco opened this issue Apr 3, 2025 · 0 comments · Fixed by #8021
Closed
5 tasks done

record caboose SIGN value in inventory #7914

davepacheco opened this issue Apr 3, 2025 · 0 comments · Fixed by #8021
Assignees
Milestone

Comments

@davepacheco
Copy link
Collaborator

davepacheco commented Apr 3, 2025

Cabooses for RoT archives and RoT bootloader archives (but not SP archives) contain a SIGN key that's a hash of the public key that the RoT needs its software signed by. Software that's updating the RoT or RoT bootloader needs this information to choose the appropriate Hubris archive. I believe that during MUPdate, we read the cabooses from the archives that we have available (from the TUF repo) and compare them to the one reported by the device and choose the one that matches. This is basically what I think the Reconfigurator planner will do when it wants to do an update.

But right now, we don't collect this value during inventory, so Reconfigurator doesn't have it available.

It'd be nice to get this in sooner rather than later so that by the time we want to use it, we can assume it will be present already in all of our inventory collections.

I imagine this work will look like this:

  • Update the inventory in-memory types (in nexus/types/src/inventory.rs) to have a separate type for cabooses that have this field. It may need to be optional at first because when we first deploy this to existing systems, the existing inventory collections won't have these fields.
  • Update the database schema for sw_caboose to have this field -- again, it'll probably have to be optional in the first release.
  • Update the database types
  • Update the database queries that read/write inventory collections
  • Update the inventory collector/builder to fetch this information

Assuming we do make this field optional in the first release, then we might have a second task to go make it all required in the subsequent release. (Alternatively, we could choose to just to assume the field is always present and simply ignore all existing inventory collections across this upgrade.)

@davepacheco davepacheco added this to the 15 milestone Apr 3, 2025
@karencfv karencfv self-assigned this Apr 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants