Repository navigation
Description
Description
Architecture and application-publishing preparation now exists in PR #401: native amd64/arm64 image jobs, verified OCI handoff and an inactive application-owned GHCR recipe. The earlier statement that no implementation PR exists is obsolete. PR #401 explicitly leaves protected publication/attestation and accepted-runtime final-image cases outstanding; this issue stays open.
Steps to reproduce
Inspect #401 architecture/artifact workflows and execute the same constrained HTTP/TLS/mount tests on each native target. In a separately authorized application release rehearsal, transfer the exact tested artifacts to the trusted publisher, verify digests/attestations and assemble the runtime index without rebuilding.
Expected behavior
Both Linux runtime variants are tested with recorded runner identity. Untrusted PR builds have read-only authority; trusted app-owned release jobs publish exactly the accepted bytes with traceable inputs, provenance/SBOM and rollback digests.
Impact
Cross-compilation alone cannot prove a runnable image; rebuilding after acceptance loses tested-artifact identity. A copyable recipe is not exercised registry/OIDC acceptance.
Proposed fix
Finish #401 preparation review, then perform remaining protected-publication and #392/#396/#275 final-image acceptance. Keep artifact identity checks, native-run evidence and application release ownership explicit. Use pinned actions/inputs, least privilege and no persistent checkout credentials. Preserve strict application scan policy, including Rust unsound warnings; distinguish framework report-only scans and reviewed OS exceptions from release acceptance. No automatic promotion of untrusted PR artifacts or public framework application image.
Done when
- Final images built from Axum: scaffold hardened production application Dockerfiles #398's recipe run on linux/amd64 and linux/arm64, with runner/emulation evidence recorded.
- Both images pass the same non-root/read-only-root, HTTP, TLS, and mount checks; runtime readiness/persistence/shutdown acceptance is added when the owning issues land.
- Pull-request execution has no publication authority or deployment secrets.
- A controlled workflow exercise proves the trusted publisher receives the tested artifacts, preserves/verifies their digests, and assembles the intended runtime platform variants without rebuilding.
- The documented downstream publishing path covers SBOM/provenance, source/lock/toolchain traceability, vulnerability policy, public pull where desired, retained digests, and rollback. Any unexercised registry-specific behavior is explicitly labeled.
- Workflow lint/security checks include the new files, and no existing native/WASM gate is weakened.
- Preparation can land independently of final production certification; remaining acceptance gaps are linked to their owners.
- No public EdgeZero application image is required; actual Trusted Server release ownership is linked rather than duplicated.
Related
- Parent Make the Axum adapter production-ready for self-hosted deployments #391; prerequisite Axum: scaffold hardened production application Dockerfiles #398 recipe; Axum: document Docker, Kubernetes, and managed-cloud deployments #400 consumes verified architecture/release behavior.
- Implementation/preparation PR Scaffold hardened Axum application Docker recipes #401; runtime Implement portable outbound HTTP and request lifecycle contracts #436 / PR feat: implement portable outbound HTTP and request lifecycle contracts #275 and Axum: define a production server lifecycle with bounded graceful shutdown #392–Axum: add safe production diagnostics and trusted-proxy handling #397.
- Provide default GitHub workflows for format, test, Dependabot, CodeQL and Docker #161 generated workflows. Downstream release/image ownership: Trusted Server #897.
Activity
[-]Axum: publish verified amd64 and arm64 reference images[/-][+]Axum: validate multi-platform containers and provide an application publishing workflow[/+]