Closed jku closed 2 months ago
The prober workflow does four passes:
On preprod vs prod:
On the two different validation cases:
repository-test
action could just have simple inputs (won't work for delegated targets but I think that's fine)
time
: reference time to run the client test at (optional, default is now)root_time
: optional. If set verify that root metadata is valid at this time (even if online roles are not)targets_time
: optional. If set verify that root metadata is valid at this time (even if online roles are not)dedup-key
output: identitifer that uniquely identifies the repository contentsThis approach sounds good. You could also consider unifying root_time
and targets_time
into offline_signing_time
or something similar, as the motivation behind the 15 day alert is to give maintainers enough time to gather all of the signatures from the keyholders.
I have an almost complete repository-test
action PR in https://github.com/theupdateframework/tuf-on-ci/pull/239
Likely the only thing missing is the selection of initial root: currently it uses 1.root.json from the repo-under-test: for rootsigning production we likely want a bit more control (since I believe the early roots are not compatible with python-tuf)
We should be able to switch probers to repository-test
even before root-signing uses tuf-on-ci.
This is done and is running in probers, seems to work pretty well
sigstore-probers has some workflows that test the tuf repository validity (now and some days into the future). These use: https://github.com/sigstore/root-signing/blob/main/cmd/verify/app/repository.go
Let's take a good look at whether we can re-implement that, maybe as part of tuf-on-ci test-repository action.
There is a bit of complexity here: