tufaceous v2 schema wishlist / thoughts

[iliana]

• Capable of having multiple system versions (for eventual TUF-via-HTTPS support)
• One-to-many relationship of logical artifacts to binary artifacts (e.g. host OS image is made up of a gimlet phase 1 ROM, cosmo phase 1 ROM, phase 2 image, possible future bonus kinds) instead of shipping a tarball and expecting the rack to know how to unpack artifacts of our build process
• Richer artifact metadata, such as the SIGN field on the hubris archive cabooses (we should evaluate what other information wicket/nexus are needing to extract from artifacts)

[jgallagher]

We now have distinct gimlet and cosmo bootloaders, but the artifact kind we use for sleds is named after gimlet:

tufaceous/artifact/src/kind.rs

Line 195 in db07274

GimletRotBootloader,

This lead us to creating TUF manifests that look like this:

[[artifact.gimlet_rot_bootloader]]
name = "gimlet_rot_bootloader-staging-devel-gimlet"
version = "1.4.1"
[[artifact.gimlet_rot_bootloader]]
name = "gimlet_rot_bootloader-staging-devel-cosmo"
version = "1.4.1"

where we treat the cosmo as "a gimlet with a different BORD and SIGN". Works fine, but is confusing.

[lzrd]

The SP/RoT CI HW in the loop testing downloads and uses TUF repos.
Claude-collaboration library to deal with download/extract-from a tuf repo is in a branch right now after re-write of get-tuf-repo.sh in rust.

I was planning to pull out the code into a CLI to replace the script embedded in building-tuf-repo.adoc.