v0.33.0 release is blocked: ten expired risk acceptances and incomplete Scheduling image onboarding

[jeremi]

Recorded 2026-09-22 after taking the v0.33.0 release as far as it can go without an owner decision. Two blockers, both upstream of request-candidate. Neither is a time problem.

Blocker 1: ten expired risk acceptances (owner decision)

CVE-2026-5435 (libc6 2.41-12+deb13u4) and CVE-2026-85091 (zlib1g 1:1.3.dfsg+really1.3.1-1+b1), both High, both accepted_risk, are excepted in five advisory baselines:

Baseline	Exceptions	expires_at
release/security/breg-advisory-baseline.json	2	2026-09-18
release/security/casework-advisory-baseline.json	2	2026-09-18
release/security/discovery-advisory-baseline.json	2	2026-09-18
release/security/evidence-advisory-baseline.json	2	2026-09-18
products/relay-v2/security/advisory-baseline.json	2	2026-09-18

Today is 2026-09-22, so every one is expired. check-advisory-baselines.py walks each exception unconditionally and appends expired exception: <key> when expires_at < today. Deleting the exception instead does not help: an exception whose finding is still present is required, and a finding without one fails as fixed or absent finding still has an exception. The gate runs in release-candidate.yml during request-candidate, so it stops the candidate build, not the tag.

registry-release renew-advisory-baselines cannot clear this. It moves evidence bindings only; it refuses expired exceptions and never writes a rationale or extends an expiry. That refusal is deliberate: the accepted risk is owned by a person, and the rationale names @jeremi.

This is not a re-dating exercise. The accepted rationale rests on "Debian classifies the Trixie issue as minor/no-DSA and has no Trixie fix", reviewed 2026-09-15 against the pinned base gcr.io/distroless/cc-debian13:nonroot@sha256:c31ff9ab.... That base has since moved upstream to sha256:54df941e..., and dependabot #1194 would take that bump together with rust 1.95 -> 1.97. So the premise needs re-checking before the acceptance is renewed.

Two routes, and they are genuinely different decisions:

1. Re-accept. Re-verify that Trixie still has no fix, then set a fresh reviewed_at and expires_at across all five baselines and record why. Cheapest, and leaves the base image stale.
2. Take the base bump. Merge chore(deps): Bump the docker-images group across 1 directory with 2 updates #1194 (or its successor) and re-baseline. Note that chore(deps): Bump the docker-images group across 1 directory with 2 updates #1194 predates Scheduling and does not touch release/docker/Dockerfile.scheduling, so taking it as-is leaves the sixth image on the old base. That divergence has to be closed in the same change.

Blocker 2: Scheduling image onboarding is incomplete

v0.33.0 is the first release to build six images: breg casework discovery evidence relay scheduling (release_candidate.py image-names --version 0.33.0). Against OPERATIONS.md "Onboard a new release image", which is explicitly to be completed outside the release clock:

• Step 2, release/docker/Dockerfile.scheduling: done.
• Step 3, GHCR identities scheduling (public) and scheduling-candidate (private): not done. Both report absent. Worth confirming in org package settings, because the token used here lacks read:packages; it did return a distinguishable 403 for an existing package against 404 for these two. This step needs a classic PAT with write:packages and a manual visibility change in the org UI, so it cannot be driven from an agent session.
• Step 4, scheduling-candidate in CANDIDATE_PACKAGES in release/scripts/cleanup-release-candidates.py: not done, correctly so. The allowlist fails closed on an absent package, so this must follow step 3, not precede it. scheduling is already in PUBLIC_PACKAGES.
• Steps 5 and 6, release/security/scheduling-advisory-baseline.json: not done. The file does not exist. It has to come from a named baseline-bootstrap rehearsal with advisory_evidence=true against a clean committed unopened release branch, then be authored from that artifact's exact image evidence. OPERATIONS.md forbids copying another product's baseline or adding a provisional bypass.
• Step 7 gates the version-preparation PR on onboarding plus a strict rehearsal both passing.

Because step 7 puts the version-preparation PR after onboarding, registry-release prepare was not run and that PR was not opened. Doing so would start the release clock ahead of the documented order.

Ordered path to a candidate

1. Decide blocker 1 (re-accept, or take the base bump and re-baseline).
2. Provision the two scheduling GHCR package identities (classic PAT, plus the org visibility change).
3. Add scheduling-candidate to CANDIDATE_PACKAGES with its test.
4. Run the baseline-bootstrap rehearsal, author and merge release/security/scheduling-advisory-baseline.json.
5. Apply the blocker-1 decision to all five existing baselines.
6. Protected-main CI plus the strict read-only rehearsal.
7. registry-release prepare, version-preparation PR, then one candidate.

Already done toward v0.33.0

A mechanically collected change inventory sits at /private/tmp/v0330-notes-fresh.md (30 merged PRs since v0.32.0 at 22ea9228), and an authored draft of the notes at /private/tmp/v0330-notes-authored.md. Both are local scratch on this machine, not committed. The release is materially larger than a normal cut: a new runtime product (Registry Scheduling), a new deterministic Typst renderer (registry-render), a PostgreSQL 17 requirement, a wire-breaking hook contract adopted across products, and field-level encryption for restricted fields.

[jeremi]

Verified the blocker-1 details against the tree rather than leaving them asserted:

• Every one of the six release/docker/Dockerfile.* runtime stages, Scheduling included, is pinned to gcr.io/distroless/cc-debian13:nonroot@sha256:c31ff9abcb1910f3ab25c7957bdaf0bfe12a01eb546e8df2282f1c8f682b606c, the base the 2026-09-15 acceptance was reviewed against.
• chore(deps): Bump the docker-images group across 1 directory with 2 updates #1194 moves that pin to sha256:54df941ed0d06a1bd95ef5e0ce391fd8d9f94b64782dc9a60062727849ee3f97 in exactly six files: Dockerfile.breg, Dockerfile.builder, Dockerfile.casework, Dockerfile.discovery, Dockerfile.evidence, Dockerfile.relay. It does not touch Dockerfile.scheduling.
• The reason is timing, not an exclusion: chore(deps): Bump the docker-images group across 1 directory with 2 updates #1194 opened 2026-09-20, and Dockerfile.scheduling first reached main on 2026-09-21 with "feat(scheduling): Registry Scheduling MVP" (feat(scheduling): Registry Scheduling MVP #1092). So route 2 means rebasing chore(deps): Bump the docker-images group across 1 directory with 2 updates #1194 or reopening it, not merging it as it stands, or the sixth image silently keeps the old base while the other five move.

Nothing here decides between the two routes. It only removes the guesswork from route 2.

[jeremi]

Authored draft of the v0.33.0 release notes, parked here so it survives /private/tmp and is in reach when the release resumes. It is a draft: it was written from the 30 merged PRs and their changed paths, and while the compatibility section was the focus, individual claims (version numbers, code names, exact refusal codes) have not each been re-verified against the running binaries. Treat it as a strong starting point for registry-release draft-notes output, not as reviewed copy.

---

Registry Stack v0.33.0

Registry Stack v0.33.0 is the beta-45 release. It ships Registry Scheduling as
a fifth runtime product, moves approval of Base Registry Engine change requests
out of the engine and into Registry Casework, and gives every product one way
to declare and run hooks over one shared envelope. Base Registry Engine also
adds field-level encryption for restricted fields and durable, resumable
ingestion runs. PostgreSQL 17 is now the Base Registry Engine floor.

Compatibility and migration

• BREAKING: Base Registry Engine requires PostgreSQL 17 or newer. Its
  closed-catalog check expects the MAINTAIN owner privilege PostgreSQL
  introduced in 17. Upgrade the registry database before starting v0.33.0.
• BREAKING: entity events are authored under hooks:. entities[].events and
  extendEntities[].events are refused at compile time with
  entity.events.removed. Rename the member to hooks, add phase: after to
  every hook, replace webhook: {destinationId: X} with handler: {kind: url, destinationId: X}, and run bregctl project lock PROJECT. Runtime
  eventDestinations and the event.* codes are unchanged. caseworkctl source add writes the new shape; a registry connected by an earlier
  caseworkctl needs rewriting.
• BREAKING: the shared hook envelope is now the stored and delivered body for
  every hook and destination kind, and X-Registry-Signature covers exactly
  those bytes, so every receiver of an event delivery sees a changed body.
  Registry Casework is updated in the same release; check any other receiver.
  Drain the outbox before upgrading, or let it settle: a row captured under the
  earlier body is not an envelope, so the worker refuses it as a failed attempt
  and it dead-letters once its budget runs out.
• BREAKING: change-request review moves to an external authority.
  changeRequest.review.mode and changeRequest.review.stages are gone:
  author review.authority and review.policyId, and rename application to
  onApproved. approve_request, reject_request, and request_revision
  were removed from profiles, and per-stage reviewStages targets give way to
  a top-level applyTargets list. Add a reviewAuthorities runtime entry per
  authority id with endpoint, profile, producerId, and recoveryDays;
  bregctl dev and source add --apply write it and the Casework binding.
• BREAKING: Registry Casework replaces hosted decisions with unified reviews.
  /v1/hosted-items, /v1/hosted-accountability, hosted-decisions, and
  hosted-history give way to /v1/review-requests, /v1/review-kinds,
  /v1/review-results, /v1/review-tasks, and /v1/review-accountability.
  One 0015_unified_reviews.sql migration creates the review schema and drops
  the experimental casework_hosted_* tables, carrying no data over. Export
  what you need first.
• BREAKING: the Version 1 hook delivery signing and verification helper in
  registry-platform-crypto is renamed from breg_webhook to
  delivery_signature. The signing domain, the field order, and the bytes on
  the wire are unchanged; only the Rust name moves.
• BREAKING: evidencectl JSON report codes and paths are renamed. Refusal
  codes are namespaced as evidence.<area>.<rule> (question-parse becomes
  evidence.question.parse), authoring-crate codes under
  evidence.authoring.<code>, and field paths are RFC 6901 pointers
  (artifact:.a[0].b becomes artifact:/a/0/b). A refused report carries
  ok: false and status: refused, omitting a passing report's detail keys.
• BREAKING: action.handler.script_forbidden, action.handler.script_missing,
  action.handler.module_forbidden, and action.handler.module_missing were
  removed. A mispaired handler is now refused when the project is read, as
  source.shape.invalid naming the member; match it and
  action.handler.kind.unsupported instead.
• Registry Casework admits only the RFC 9068 access-token type. An issuer that
  mints typ: JWT access tokens for the Casework audience must be configured
  to mint at+jwt or application/at+jwt before upgrading.
• The wasm cargo feature is now a default feature of registry-breg and
  registry-bregctl. A source build can opt out with --no-default-features
  and still refuses kind: wasm by name; release builds do not use it.
• bregctl data import refuses an import checkpoint written before ingestion
  runs, because resending its committed items under a new run id would
  duplicate mutations. Start a new import with a fresh checkpoint path.
• Registry Scheduling's contract is unreleased and carries no frozen
  compatibility promise in this release.

Registry Scheduling

Registry Scheduling is the fifth independent runtime product: it publishes
bookable services over anchored supply and gives authorized callers short holds
and confirmed appointments, and its scheduling runtime image joins the
published release roster from this version. It owns its capacity ledger
absolutely, writing it only inside its own capacity transaction, while
eligibility stays with the source system, and every commitment carries a task
grant whose bounds name the offering's service, location, and action, with the
grant's expiry re-checked inside that transaction. Delivery is outbox work:
only after URL observers are accepted, and conditions, principals, local
handlers, and observer proposals are refused.

Approval ownership moves into Casework

Registry Casework is the sole owner of external and standalone review lifecycle
state, reached through the source-neutral contract in
registry-review-protocol and registry-review-client. A review kind may
declare a closed resultSchema beside its display schema, an outcome may set
resultRequired, and a Requester may narrow declared fields per request with
resultConstraints. Results erase with the display payload at terminalDays,
after which the accountability record keeps only a sha256 digest until
accountabilityDays closes. Profiles gained readableRequestFields for the
fields an external reviewer must read.

One hook contract across products

Hooks are declared once, in the shared registry-platform-hooks contract: a
product-owned trigger, a phase, and a handler that is Rhai, WASM, or a remote
URL, every kind taking an envelope in and returning a message out. The envelope
is one canonical JSON document carried unchanged to every destination kind,
with causation naming root, hop, and parent, and the delivery core the
Base Registry Engine owned now lives in the library. A handler answers with one message: a proposal, nothing, or a refusal. A hook
may declare a principal, and the engine applies its proposal as an
authorized, validated mutation in a fresh transaction, once per delivery across
attempts and replays; a proposal from a hook with no principal dead-letters as
hook.proposal.no_principal, and a hop past the causation ceiling of 8 is
refused before it is enqueued, so a loop terminates and dead-letters.

WASM action handlers

The shipped breg and bregctl binaries admit kind: wasm action handlers
without a custom build, so they now match what the authoring schemas already
published. The executor is Wasmtime 48.0.2 on its LTS patch stream, with a
fresh store and instance per call, fuel plus epoch deadlines, and a
deny-and-record memory limiter. An optional wasmExecution runtime section
carries maxModuleBytes, maxGuestMemoryBytes, and backend, defaulting to
pulley. A handler cannot declare registry.action-handler/v2, so
it cannot call evidence::resolve, and WASM change-request planners stay
expressible but refused in every build.

Base Registry Engine records and data

• A restricted string, text, date, decimal, or structured field may declare
  encrypted: true, with an optional lookup block of closed-vocabulary
  normalization steps and a unique flag. Values are sealed with envelope
  encryption and stored as ciphertext plus an HMAC blind index, decrypted once
  at an enumerated caller-authorized response edge, on the AWS-LC FIPS build.
  The guarantee covers direct database reads, not the serving process.
• Turning encryption on for a field with existing rows is a reviewed migration
  that seals existing values, drops the plaintext column, and must choose its
  history treatment: erase-and-rebaseline destroys the per-record history
  once the successor package activates, retain-plaintext-history does not.
• Ingestion is durable and resumable. POST /v1/records/{route}/ingestion-runs
  opens a run from an announced binding, the client submits bounded chunks, and
  the server commits each chunk's mutations, revisions, audit entries, receipt,
  and checkpoint in one transaction. A changed active package revision blocks
  the run with blockedReason: activePackageChanged, and a divergence is
  refused with 409 ingestion.chunk_mismatch rather than skipping rows.
• approve_request and apply_request accept the same optional bounded reason
  that reject_request and request_revision already accept, recorded on the
  decision entry and the application receipt and bound into the action binding.
• The Rust, Node.js, and Python clients expose the ingestion run surface and
  add typed retained history pages, proposals, and applied-result references.

Development and tooling

• evidencectl reports machine-readable failures: generic JSON failures carry
  a cause field with the chain detail the human renderer prints, seven more
  commands accept --format json, and evidencectl help --format json and
  bregctl help --format json render the registry.cli-reference/v2 catalog
  for the invoked binary. A new offline-starter project passes check and
  test with no import.
• Casework reads stay available while a subject's source binding has moved but
  reconciliation has not applied it: the retained occurrence is returned
  without actions, and acting on it refuses with work-item.proposal-changed.
• A token response stating an empty scope is read as granting no scope
  instead of refused as malformed, so a private-key-JWT provider that requested
  no scope now uses that credential; one that requested scopes still refuses it.
• Identifier publication is bound to the exact released source catalog digest.

Changes since v0.32.0.
This remains a pre-1.0 Beta release for self-hosted institutional pilots.

[jeremi]

Open questions in the release-notes draft

The draft in the comment above is authored, not mechanical, so it makes
judgement calls. These are the ones worth a second opinion before publishing.
Everything else in it was checked against the code in this repository.

Deliberately omitted, because I could not establish they belong in v0.33.0:

1. registry-render (feat(render): registry-render, a deterministic Typst document renderer #1113, fix(render): bind sealed bytes to rendering #1174) is not mentioned at all. It is absent
   from the release inventory in release/scripts/registry-release, and in
   the root Cargo.toml only registry-cli-docs depends on it. I could not
   establish that it is visible to an adopter in a shipped artifact. That
   leaves 2 of the 30 merged PRs uncovered. If the Typst renderer is meant to
   be part of this release's story, it needs a section and probably an
   inventory entry.
2. Two breaking records in products/breg/HISTORY.md, the Registry Record
   profile change and plural catalogue resources, are omitted. Both are real,
   but I could not tie either to a PR merged in this window, so they may
   predate v0.32.0.
3. fix(breg): require PostgreSQL 17 #1161's note that a PostgreSQL 16 to 17 major upgrade of a live registry
   changes the fingerprint. The compatibility bullet says only "upgrade the
   registry database before starting v0.33.0". Whether an operator must
   re-baseline or re-lock after the upgrade is the missing half, and it is the
   half an operator needs.
4. The pre-Version-1 webhook history migration sentence in
   EVENTS-AND-WEBHOOKS.md, for the same reason as item 2.

Claimed narrowly, on purpose:

5. The Scheduling paragraph claims only that the scheduling runtime image
   joins the published roster. It does not claim schedulingctl binaries,
   installers, or Scheduling entries in the unified Node.js and Python client
   facades, because _expected_artifact_inventory in release_candidate.py
   does not add them and Scheduling: publish binaries and an installer, or keep the README honest #1240 and Scheduling client is absent from the unified Rust, Node.js, and Python facades #1241 are still open. If those land, the
   paragraph needs widening.
6. "WASM change-request planners stay expressible but refused in every build"
   rests on action.handler.wasm_build_unsupported in
   crates/registry-breg/src/immediate_actions.rs, not on an end-to-end run.
   The rest of that paragraph is verified against the pinned
   wasmtime = "=48.0.2", the default = ["wasm"] lines in both manifests,
   and the wasmExecution block in runtime.schema.json.

One conflict, resolved: #1189's body says "Migrations 0016 and 0017 are one
unreleased delivery", but crates/registry-casework/migrations/ on main
stops at 0015_unified_reviews.sql, and products/casework/CHANGELOG.md names
exactly that one. The draft says 0015_unified_reviews.sql. Verified against
origin/main after the draft was written: 0015 is the last migration, so the
PR body is stale and the draft is right.

Length: 157 lines against a 90 to 150 target. The compatibility section is
55 of them, because this release has 12 operator-visible compatibility items
where v0.32.0 had 4. If it needs to come down, the three cheapest cuts are the
registry-review-client and resultConstraints clause in the Casework
section, the Wasmtime executor-internals sentence, and the BReg clients bullet.

Accurate but cut for length, in case any of it is wanted back: the hook
proposal dispositions and the codes hook.proposal.precondition_failed and
hook.proposal.answer_conflict; hook.phase.unsupported and the before plus
url refusal spelled as hook.handler.kind.unsupported; the delivery-core
relocation; the field-encryption guarantee boundary (serving process, key
transit credential holder, pre-flip backups) and the four unsupported phase-1
operations; readableRequestFields; Scheduling's MVP surface enumeration and
the schedulingctl subcommand list; the ingestion run states; and the
release-provenance identifier-publication bullet from #1183.

[jeremi]

Status at hand-off. Both PRs that were to go in ahead of the release are merged: #1271 (explain wire contract, six ranked fixes) and #1276 (review model, engine lifecycles, every authored source; closes #1245 and #1267). main carries them, CI is green, and no release-content work is outstanding.

The two blockers in this issue are unchanged, and neither is a matter of time:

1. Ten expired risk acceptances across five advisory baselines. Renewing them is accepting known vulnerabilities for a further period, which is a security decision rather than a mechanical step, so the gate at request-candidate stays closed until an owner renews them.
2. Scheduling image onboarding is incomplete, and GHCR provisioning needs a classic PAT the release path cannot mint for itself.

Five further findings on the lifecycle guard prose from the last review round are filed as #1280, out of the release path.

[jeremi]

Blocker 1 is addressed by #1283, taking route 1 (re-accept) on the owner's decision.

The ten acceptances now run 2026-09-22 to 2026-10-06, a 14-day window matching every prior renewal in these files. Re-verified against the Debian security tracker on 2026-09-22: Trixie is still vulnerable and unfixed for both CVE-2026-5435 (glibc, no-DSA minor issue, fixed only in forky and sid) and CVE-2026-85091 (zlib, no fixed version recorded anywhere). The premise this issue flagged for re-checking therefore holds: every release Dockerfile still pins the same cc-debian13 base digest the five baselines record, so the upstream tag having moved changes nothing until that pin is bumped.

One correction to the framing above. Renewing the acceptance does not by itself let a v0.33.0 candidate pass the advisory gate. The exposure assertions are whole-image fingerprints bound to the v0.32.0 images, so a rebuilt candidate fails them on file digests regardless of dates. The bindings still have to be renewed from a rehearsal artifact at prepare time, which is the ordinary documented step. What the expiry was blocking is that step itself: renew-advisory-baselines refuses the whole roster on an expired exception and never extends an expiry. So #1283 unblocks the tooling rather than the gate.

Blocker 2 is untouched and still needs the classic PAT and the org visibility change.