v0.0.41

Substitute from the release cache

Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:

extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=

Upgrade guidance

Reuse of stored NARs

A push reuses a NAR that the tenant already stores only if the push can already
read it. A readable reference to the NAR must belong to the destination cache, a
public cache in the tenant, a cache covered by cache:content-read, or a cache
in a reuse view covered by view:content-read. Earlier releases reused a NAR
that any cache in the tenant referred to.

Some pushes that skipped the upload in earlier releases now upload the bytes.
This happens when only private caches that the push token can't read refer to
the NAR. For example, a pull-request job that pushes to a public pull-request
cache now uploads a path that only a private cache has.

Publishing by reference from a private cache or a private reuse view needs the
same grant on the push token when the source differs from the destination.
cupboard push now requests cache:content-read or view:content-read for
each private source in the same tenant, whether the source is given with
--reference-source or in a reference manifest. A token request is all or
nothing, so if the trust rule does not permit the grant, the push gets no token
and reports the refused request with its private sources.

A tenant whose flake publish workflow reuses paths from a private reuse view
must permit view:content-read for that view in the trust rule of its branch
runs. This applies whether the workflow reads the view through OIDC or with a
static read credential. cupboard github check reports the missing grant, and
its guided repair adds it.

cupboard still stores each NAR once.

Use cupboard check --shared-access <tenant-url> to review NARs that public and
private caches both reference. The report requires check:run and changes no
publications.

Control database split

This upgrade moves control keys, trust rules, operator sessions, consumed
subject nonces, the administrator record and maintenance reports from
CUPBOARD_DB to CONTROL_DB. Only the control Worker receives the new binding.
The shared store and tenant registry remain in CUPBOARD_DB.

Use cupboard deploy or cupboard init. The command prepares both schemas,
uploads compatible Workers, freezes legacy control mutations, copies the rows in
bounded pages, checks complete source and target contents, and validates wrapped
signing keys with the control Worker's existing wrapping secret. It then
publishes target readiness and removes the old control tables. Preserve
CONTROL_KEY_WRAP_SECRET; replacing that secret prevents key validation.

The migration assumes that the legacy database has not been compromised. Key
validation checks the wrapped private material, matching public keys and unique
key IDs. The database contains no authenticated writer history for trust rules,
administrator records or key metadata. If compromise is suspected, establish
independently reviewed authority data before upgrading. The copy cannot identify
a correctly shaped forged authority row.

The cutover is irreversible. Both Workers add an unbound Durable Object class so
Cloudflare refuses dashboard rollback across the release. Before freezing, the
deploy also records the shared control-database-split contract marker so older
cupboard deployment tools refuse the database. See Cloudflare
rollbacks.

While the source is frozen and the target is incomplete, control token issuance
and authority mutations return a temporary failure. Existing tenant cache
traffic continues. Refresh families, spent members, retry envelopes, revoked
sessions, disabled trust rules, retired keys and consumed nonces retain their
stored values.

If the command stops, rerun the same deployment with the same database bindings
and deployment URL. The deploy recognises reciprocal source and target markers
and the irreversible contract marker on an unfinished transition. Cloudflare
deployment credentials permit that forward recovery even if the source cannot
renew an administrator token. Normal administrator authentication is required
once the cutover transition is complete. The command installs a temporary
control-only validation secret for its key check and removes that secret
afterwards.

A mismatched target row or invalid key stops the copy before readiness. Preserve
both databases and correct the reported problem, then resume. Do not clear the
source freeze marker, replace target authority from the stale source after
readiness, or deploy a preceding release. A ready target is authoritative and
can already contain newer revocations and sessions.

What's Changed

• test(scripts): isolate git fixtures from the caller's repository by @iainlane in #464
• fix(server): fail the commit fixture when its passes run out by @iainlane in #465
• fix(server): preserve deferred verdicts and release ignored claims by @iainlane in #470
• fix(cli): exit 75 only for transient GitHub OIDC failures by @iainlane in #469
• fix(server): isolate control authority in a separate database by @iainlane in #471
• fix(publication): require readable authority when reusing stored NARs by @iainlane in #472

Full Changelog: v0.0.40...v0.0.41