Migrate release runtime images from Debian 12 LTS before 1.0

[jeremi]

Context

Registry Stack release and product Dockerfiles currently pin Debian 12 Bookworm or Distroless Debian 12 images. Debian transferred Bookworm from regular security support to LTS in July 2026 and recommends Debian 13 where possible. Grype 0.114.0 consequently warns that Debian 12 vulnerability data may be incomplete or outdated.

The beta-12 source-candidate scan also found one fixable Medium finding in the pinned Bookworm base (liblzma5 5.4.1-1, fixed by 5.4.1-1+deb12u1). Current Bookworm images contain the fix, but the pinned release base predates it. The reported High/Critical Bookworm findings had no fixed Bookworm package in the scan and require normal reachability/issuer triage rather than a zero-CVE claim.

This does not block publishing a candidly evidenced beta, but the 1.0 runtime and scanner support boundary should be unambiguous.

Official lifecycle notice: https://www.debian.org/News/2026/20260712

Acceptance

• Move release Relay and Notary runtime images to supported Debian 13/Trixie and Distroless Debian 13 bases, pinned by immutable multi-architecture digest, or document and approve a concrete Debian 12 LTS exception.
• Align maintained product Dockerfiles and the release Dockerfiles so local/preflight images do not silently test a different OS support boundary.
• Verify Notary PKCS#11 runtime libraries, CA roots, non-root behavior, permissions, and readiness on the chosen base.
• Verify Relay non-root runtime files, CA roots, worker execution, and readiness on the chosen base.
• Rebuild with the release workflow, produce SBOM and Grype evidence, address every fixable finding, and record reachability decisions for remaining High/Critical findings without claiming zero CVEs.
• Run the maintained Registry Stack image checks and the standalone Solmara implementer smoke with one Notary per Relay authority.
• Document the supported runtime-base lifecycle and digest-refresh expectation for implementers and release operators.

Non-goals

• A generic container-base abstraction.
• Unrelated dependency or application hardening.

[jeremi]

Maintainer decision required before implementation

The repository currently exposes multiple valid-but-incompatible #380 paths, so an implementation worker must not choose one implicitly.

Please record these choices:

1. Runtime OS policy:

   • Recommended: migrate maintained runtimes to Debian 13.
   • Alternative: retain Debian 12 only through a scoped exception with owner, expiry, covered architectures/packages, scanner-data treatment, and a review trigger.

2. Notary runtime shape:

   • Recommended: align product and release Notary on gcr.io/distroless/cc-debian13:nonroot, keeping vendor PKCS#11 modules external and proving module loading.
   • Alternative: align on debian:trixie-slim, accepting the additional shell/package-manager surface and defining reproducible APT policy.

3. Demo scope:

   • Recommended: migrate the active Relay demo Dockerfile too.
   • Alternative: explicitly exclude it from the supported runtime boundary.

4. Builder scope:

   • Recommended: keep existing builders unchanged in Migrate release runtime images from Debian 12 LTS before 1.0 #380. Builder migration affects repeatable binary output and should be a separate packet.

After the decision, the implementation packet should align product and release Dockerfiles, enforce immutable multiarch base pins, add executable non-root/read-only-filesystem/worker/health/TLS/PKCS#11 checks, fail on every fixable vulnerability, require current dispositions for remaining High/Critical findings, and bind SBOM/scan/capsule subjects to the exact pushed digest. Candidate-only publication and Solmara evidence must remain separate from implementation-PR evidence.