sigstore
Publishing state (prod/preprod) should be more visible
It is difficult to see what is currently available in prod and preprod, compared to git content -- and difficult to see if their current state is a result of correct operation or a publishing issue.
I don't know what the correct fix is: just throwing some ideas out there:
- An action that runs after every sync (and maybe also on cron) that actually fetches the prod, preprod and git main branch metadata as a TUF client, and publishes the received metadata version numbers (at a minimum root+timestamp) on a web page somewhere
- In the sync* GitHub actions, once the process is successful, move a git tag or a branch to point to the commit that was synced
- other approaches? Is there a solution where it's easy to tell which environments a particular PR has reached?
Out of these I like option 1 because it actually documents what clients see, not what our CI/CD thinks the sync state should be: It could also be further improved by sanity checks that file issues if the versions are not what we expected.
Option 1 is similar to tuf_client_tests.yml, except
- depends on prod and preprod to be reachable
- publishes metadata versions somewhere
- optional sanity checks on expected metadata versions
It is difficult to see what is currently available in prod and preprod, compared to git content -- and difficult to see if their current state is a result of correct operation or a publishing issue.
Weirdly enough I had a dream this weekend where we dynamically published the values on the root-signing repository. +1 to this idea!
a web page somewhere
Having a table on the sigstore dashboard would be good -- the probers can probably manage this. I'm not sure how the sigstore dash is built or where it's hosted/what we can put on it, but that would b likely be the best way for on-callers to monitor state as well.
@priyawadhwa is the sigstore dashboard a thing or an idea? We can probably just start with a root-signing status page too.
Idea, it hasn’t been created yet. However, it was meant for debugging purposes and would be internal, not for public consumption, probably using Cloud Monitoring. If you want it for TUF, I’d create something else.
The implementation if tuf-on-ci is not perfect but it's an improvement IMO:
- it moves publish branch when main is in a state ready for publish -- so a commit in publish branch does not guarantee that the content has been published all the way to GCS
- publishing itself is more automatic: if the client tests pass on preprod, then content will move to GCS bucket
- the status pages for preprod and prod will document the current published state (versions and the commit): https://sigstore.github.io/root-signing/, https://tuf-repo-cdn.sigstore.dev/index.html
- there are cron driven tests that will start complaining if published repository does not match publish branch contents
closing as "mostly implemented"