TUF test fixtures recur every 6 months due to hardcoded scaffolding expiry

[nellshamrell]

Background

PR #2000 (Fixes #1999) regenerated the expired TUF test fixtures across three packages:

• pkg/reconciler/trustroot (embedded testdata/*)
• pkg/apis/policy/v1alpha1 (inline validRepository / rootJSON blobs)
• pkg/tuf (inline validRepository / rootJSON blobs)

That unblocks CI, but it is a recurring papercut: the fixtures now expire on 2027-01-28, and CI will go red again then, on main and every open PR, with final root.json is expired.

Root cause

The fixtures are generated by hack/gentestdata/gentestdata.go (make generate-testdata), which calls scaffolding/pkg/repo.CreateRepoWithOptions. Scaffolding hardcodes:

// scaffolding/pkg/repo/repo.go
expires := time.Now().AddDate(0, 6, 0) // 6 months

So every regeneration is only valid for 6 months, and there is no knob to extend it. The same expiry is baked into the committed fixtures, so the whole cycle repeats.

Proposed options (in rough order of preference)

1. Generate fixtures at test time for the packages that can support it (e.g. pkg/tuf and pkg/apis/policy/v1alpha1), so now + 6mo is always in the future and the fixtures never expire in CI. pkg/tuf/repo_test.go already contains a createRepo helper using go-tuf's *WithExpires APIs that could be the basis. Caveat: scaffolding's CreateRepoWithOptions writes to a fixed /tmp/tuf path, so a runtime approach should use t.TempDir() / an in-memory store to avoid cross-package collisions.
2. Inject a controllable clock / expiry into the TUF client validation used by tests, so expiry can be pinned deterministically.
3. Upstream a configurable expiry in scaffolding/pkg/repo (e.g. a CreateRepoOptions.Expires field), then set a long-lived expiry in gentestdata.go. This also benefits other scaffolding consumers.
4. Interim mitigation: a scheduled CI job (or a documented calendar reminder) that runs make generate-testdata + re-encodes the inline blobs and opens a refresh PR before each expiry.

The golden-comparison fixtures in pkg/reconciler/trustroot are harder to move to pure runtime generation (they're compared against committed marshalledEntry.json etc.), so options 2–4 may fit those better than option 1.

Acceptance

• TUF-fixture-dependent tests no longer fail purely due to the passage of time, or the recurrence is reduced to an automated, low-effort refresh.

Follow-up to #1999 / #2000.