[tuf] Store rkth/sign hashes in TUF repo description #8729
Conversation
karencfv
changed the title
There was a problem hiding this comment.
Thanks for taking a look @iliana!
This makes me lean toward having a signed_by_rtkh: Option<Vec> on the external TufArtifactMeta. This is not something we have to do in the db-model structs; we can fill in the signed_by_rtkh field when we convert from the db-model crates to the external crates in the into_external function.
😄 , That's exactly what I had in the first iteration of this PR. Frankly, it'll be much easier to use the sign in the planner if it's contained in TufArtifactMeta so I'm all for keeping it this way. I've made the adaptations and I think this is ready for another review
There was a problem hiding this comment.
I think the mechanism here is fine, and the implementation straightforward enough. My main comment is about the terminology, and so the field names.
The SIGN field of a Hubris archive intended to run on a RoT contains an LPC55 RKTH value. But those are separate concepts, and the caboose is independent of RoT/SP. I think the only real advantage of using the name sign over rkth is that it allows for the future possibility of signed SP images (which won't use a RKTH, they'll use something else). To support that future without coming back and renaming everything here, I think we should call this field just sign, and similarly drop the rot_ prefix from the names of all associated database tables, columns, fields, etc.
If we don't want to go in that direction, then I think we should call this field rot_rkth. But I think rot_sign isn't ideal.
…TufArtifactMeta::board`) (#8872) When trying Reconfigurator-based updates on a racklette today with a real TUF repo, the planner skipped all the RoT bootloader and RoT updates because none of the artifact `name`s matched the `board`s reported in inventory. Our tests were assuming these were the same (and in prod they _are_ the same on the SP), but in real TUF repos these don't match: all the RoT and bootloaders report a `board` of `oxide-rot-1`, but the artifact names are pretty varied. This PR adds a new `board` value to the `tuf_artifact` table and the `TufArtifactMeta` struct. Outside of tests, the changes are almost identical to those from #8729 that added a `sign` field in this same spot. This allows us to stop assuming that `artifact.name` == `inventory_caboose.board`, and instead check `artifact.board` == `inventory_caboose.board`. It depends on oxidecomputer/tufaceous#40, which changes the way our fake data is generated to be more consistent with the state of production devices and artifacts. This perturbs some of the reconfiguartor-cli tests a bit, which significantly inflates the diff; the actual code changes here are pretty small.
3 participants
This commit introduces a new field in
TufArtifactMetathat maps an RoT/RoT bootloader artifact with its associated sign. This will be necessary for the planner to support RoT and RoT bootloader updates.NOTE: There is still a test failing. I'm going to investigate what's going on, but I'd like to set this PR as ready to review to get comments on the structure of the tables, etc.