jku
commented
4 months ago What is root-signing-staging?
root-signing-staging enables secure delivery of the Sigstore staging trust root to Sigstore clients. The system regularly publishes TUF metadata (a bunch of json files) through GitHub Actions and pull requests. It is secured by the metadata being digitally signed with both hardware keys and an online key management system.
There is an example signing event with some comments (including a screenshot of the signing tool) in https://github.com/jku/tuf-demo/pull/93
Current state
root-signing-staging is operational with the following caveats:
- There is only one signer currently. This is not a security issue as much as it is a reliability issue: Losing the only Yubikey would prevent further updates to root-signing-staging
- TUF metadata is not yet published to the official URL https://tuf-repo-cdn.sigstage.dev, only to testing URL https://sigstore.github.io/root-signing-staging/: The official URL is still published from a static file in production root-signing repository
Differences to production root-signing
At a high level root-signing staging should be familiar to those who know production root-signing: GitHub Actions handles online signing and GitHub pull requests are used to manage "signing events" (where signers collaborate to sign changes with their hardware keys using a local signing tool).
There are some major differences:
- There is almost no code in root-signing-staging itself. Instead it uses tuf-on-ci, software designed for this purpose
- The software stack changes significantly as tuf-on-ci uses Python
- Signing events (pull requests) are now guided by comments from the system
There are also some operational changes:
- Online signing is automatic and does not use PRs like the one in production root-signing
- Publishing pipeline includes smoke tests using a TUF client and multiple sigstore clients
- Deployment is currently an automatic part of publishing pipeline (but could include release reviews)
- Various smaller tweaks (single online key, longer snapshot expiry, signer identity stored in metadata)
Next steps
- Get 3-5 volunteers willing to be root-signing-staging signers and willing to test out and define the maintenance processes
- Make sure all signers are setup to sign. See #46
- Organize first signing event (to add the new signers): #31
- Start publishing to https://tuf-repo-cdn.sigstage.dev: #45
Technical details
The "stack" consist of
- Workflows in root-signing-staging
signing-eventruns whenever a signing event PR branch changes. It adds comments in the PR and makes commits in the PR branchonline-signruns on merges to main and on schedule. It creates new versions of timestamp and snapshot metadata when needed, and commits them to mainpublishis triggered by online-sign. It runs various tests on the repository and finally publishes it to GCScreate-signing-eventsruns on schedule and creates PRs when metadata roles are about to expire and need to be resigned
- Actions in tuf-on-ci: These actions are called from the workflows.
- Python commands in tuf-on-ci repo: The actions call python tools that should be considered an implementation detail of the actions
- tuf-on-ci-sign: signer and maintainer tools
Please join us (Jussi, Fredrik) to discuss the new and shiny root-signing-staging and the plans for root-signing future on Wednesday Feb 21 5PM GMT. https://meet.google.com/ert-dihk-dmk
The purpose is to share what we've built and to get a few people to volunteer as root-signing-staging signers:
I'll add some intro links/material here before the event