We released a thing: st-1.0.0

Rasmus Dahlberg, 2024-05-12.

On Thursday this week, the System Transparency project announced st-1.0.0. It is a collection of stable, tested, and documented components the project supports:

• stboot: a bootloader that boots an operating system such as Debian 12. One of the main features is network booting while enforcing m-of-n valid signatures.
• stprov: a provisioning tool that helps operators configure their platforms for System Transparency booting. For example, a network configuration and URLs for downloading the operating system can be provisioned with few keystrokes.
• stmgr: a tool that helps with formatting and signing of various images. For example, the bootloader can be prepared for writing onto a USB stick.
• docs: documentation meant for users and developers. Here you can find getting started guides, reference documentation, and other useful content.

I’m unreasonably happy to have this release out the door. Not because System Transparency is now done—it is far from done. I am happy because this makes it a lot easier for us to iterate forward from a known state. For example, we are finally in a position where it is possible to be intentional about what is (not) going to break. What changed in order to make this happen? I’d say three things:

1. The different interfaces that may break on changes have been enumerated and specified as reference documentation that our components implement.
2. The test coverage of each component has been increased significantly, both with unit tests, QEMU, and processes for testing on a Supermicro X11SCL-F.
3. We committed to have a semantically versioned collection of components that work together. The st-1.0.0 collection is supported for at least one year.

This concludes the first priority that Linus Nordberg, Niels Möller, and I set out to achieve on January 15, 2024. What happens next will probably be hashed out in this proposal sometime soon. Overall, I’d say the priorities laid out in January still remain reasonable. The main open question is which larger features to bring in and when the timing for them is right. Other than considering the readiness of the various candidate features, we’re also splitting our time with the Sigsum project. So, if we spend more time on System Transparency we’re spending less time on Sigsum. Until July, we’re picking up the pace in Sigsum.

On a personal note, I’d be pretty excited to someday have a bootloader that enforces transparency logging with Sigsum. I’d also like to experiment with an immutable build of a reproducible operating system package, such that I can meaningfully monitor exactly what is allowed to boot on my system. I think the first step for me personally is to get better at the whole immutable builds thing though. High up on my TODO list is to run System Transparency on something I care about myself, then gradually making the deployment more immutable. The good news is there is now a build guide and a stable st-1.0.0 release to start from.

Want to discuss System Transparency or the release further? Join the project’s Matrix room, which is bridged with #system-transparency on OFTC.net (IRC).