Skip to content

Boot the released cosigner in the e2e - #5

Closed
aruokhai wants to merge 2 commits into
mainfrom
cosigner-release
Closed

aruokhai wants to merge 2 commits into
mainfrom
cosigner-release

Conversation

@aruokhai

@aruokhai aruokhai commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor

The cosigner, the one guest this runtime is built to serve, now lives in vtxos/cosigner and is released as cosigner.wasm. The runtime's e2e now boots that release, so a runtime change that breaks it fails here instead of after the runtime is released.

  • cosigner.lock pins the release: v0.1.0, and the sha256 of its cosigner.wasm. Moving to a newer cosigner means editing those two lines.
  • scripts/cosigner.sh fetches that artifact into target/cosigner/. It refuses any other bytes.
  • run-e2e.sh takes GUEST_AGNOSTIC=1. It then runs only the legs that hold for any guest (the gate, the attestation and both PCRs, a restart, a substitution) and skips the ones that drive guest-http's routes.
  • scripts/ci-e2e.sh, after the example-guest run, boots the cosigner that way. The image is already built by then, so it costs only the boots.

To try a local cosigner build: GUEST_WASM=path GUEST_AGNOSTIC=1 deploy/qemu-nitro/run-e2e.sh.

What was run (on a KVM workstation)

  • run-e2e.sh with the released cosigner and GUEST_AGNOSTIC=1: PASS.
    • The attested PCR16 equals the measured one.
    • The restart resumes the same state_root.
    • The substitute is refused on PCR16.
  • run-e2e.sh with the example guest: PASS, all legs. The guards change nothing in normal mode.
  • scripts/cosigner.sh: fetches and verifies when the file is missing, and keeps a file that already matches.

What was not run

  • scripts/ci-e2e.sh end to end. The two runs above are its QEMU stages.

🤖 Generated with Claude Code

aruokhai and others added 2 commits October 15, 2026 09:43
The cosigner is the one guest this runtime is built to serve, and it
lives in its own repository now, released as cosigner.wasm. cosigner.lock
pins a release by name and sha256 and scripts/cosigner.sh fetches it,
refusing any other bytes; COSIGNER_WASM serves a local build instead,
for a change that needs both sides at once.

serve_cosigner loads it into the exported testing harness: every import
it makes links, it opens its tenant's store, and GetServerInfo answers
through the gate. A guest that is not the cosigner fails it on the route.

ci-e2e.sh then boots it under QEMU. run-e2e.sh takes GUEST_AGNOSTIC=1 to
run only the legs that hold for any guest (the gate, the attestation and
both PCRs, a restart, a substitution) and skip the ones that drive
guest-http's routes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The e2e is the one place the cosigner needs to run: ci-e2e.sh boots the
release cosigner.lock pins under QEMU. The in-process suite was a second
check of the same thing, so it goes, and cosigner.sh only fetches and
verifies; a local build goes straight to run-e2e.sh as GUEST_WASM.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@aruokhai aruokhai changed the title Serve the released cosigner, in process and under QEMU Boot the released cosigner in the e2e Oct 15, 2026
@aruokhai

Copy link
Copy Markdown
Contributor Author

Not needed: the runtime's e2e keeps its example guest, which is all it needs to test the runtime. The cosigner is exercised by the wallet's e2e, against the dev enclave image infra builds (vtxos/infra#2).

@aruokhai aruokhai closed this Oct 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant