reimplement prober?

[jku]

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.

• the idea of "alert if metadata is invalid x days from now" seems universal and is likely not much additional code
• if we can remove 500 lines of code from root-signing that would be good

There is a bit of complexity here:

• deduplication should be doable by as action output
• there have been weird issues with the prober getting stale data like https://github.com/sigstore/public-good-instance/pull/1683 -- This has been worked around by manual cache invalidation but I'm not convinced there isn't still a configuration issue somewhere

[jku]

The prober workflow does four passes:

1. verify that preprod repo is valid two days from now, contains correct artifacts
2. verify that prod repo is valid two days from now, contains correct artifacts
3. verify that root and targets are valid in preprod repo 15 days from now
4. verify that root and targets are valid in prod repo 15 days from now

On preprod vs prod:

• We could consider https://sigstore.github.io/root-signing-staging the "preprod" for staging...
• but unless we implement Deployment gating #54 it's not useful to test it here I think

On the two different validation cases:

• The basic "is repository valid in two days?" is trivial
• the other case "are root and targets still valid in 15 day" is interesting (and makes sense)
• the 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)
• repository-test action could have a dedup-key output: identitifer that uniquely identifies the repository contents

[haydentherapper]

This 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.

[jku]

I have an almost complete repository-test action PR in theupdateframework/tuf-on-ci#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.

[jku]

This is done and is running in probers, seems to work pretty well