Skip to content

Verify WASM reproducibility on every PR#5

Draft
fnando wants to merge 6 commits into
attestfrom
repro
Draft

Verify WASM reproducibility on every PR#5
fnando wants to merge 6 commits into
attestfrom
repro

Conversation

@fnando
Copy link
Copy Markdown
Member

@fnando fnando commented May 21, 2026

What

Adds a WASM-reproducibility check to the smoke-build workflow. For each of three representative contracts pulled from stellar/soroban-examples (tracked on main), the test builds twice inside the just-built image with target/ wiped between builds and asserts the resulting .wasm artifacts are byte-identical.

  • scripts/repro-test.sh — clones a contracts repo into a temp dir, then runs the double-build against each named contract. Defaults to stellar/soroban-examples@main and the three contracts token, liquidity_pool, atomic_swap. --repo, --rev, --contract, --keep-workdir overrides. Cleanup trap uses docker to wipe the target/ directories the container wrote as root, so the script leaves no mess on Linux CI either.
  • .github/workflows/build.yml — new step after the existing smoke test calls repro-test.sh against the freshly-built local image. Adds roughly 3–5 minutes per CI run.

Why

WASM reproducibility is the property SEP-58 verifiers rest on — without it the whole bldimg mechanism is meaningless. The earlier PRs in this series (publish, attestation, release) all assume this property holds. This PR proves it on every PR run, against real-world contracts that consumers actually build.

Notable choices

  • Clone, don't vendor. The contracts live in stellar/soroban-examples, not in this repo. The test driver clones at CI time. This mirrors how a real consumer uses the image (clone their contracts, docker run the build) and avoids the drift / hand-sync burden of vendoring third-party sources.
  • Track main, don't pin. A pinned release tag would hide upstream regressions until the next manual bump. Tracking main means an upstream change that breaks reproducibility — whether in the contracts themselves or revealing a bug in our image — surfaces in our CI immediately. Occasional upstream flakes are a worthwhile price for catching real breakage early.
  • Three contracts, varied surface. token (largest, full token spec + soroban-token-sdk dep), liquidity_pool (arithmetic-heavy with a num-integer external dep), atomic_swap (multi-party auth). Different SDK surfaces and codegen paths — broader catch than a single hello-world.
  • One bash one-liner per build. Each build runs as docker run --entrypoint sh -v "$dir:/source" "$image" -c 'rm -rf target && stellar contract build --locked && sha256sum target/.../*.wasm'. Single container per hash; cleanup happens inside the container so file ownership stays sane on Linux CI.
  • Same-arch only. Cross-arch byte equality is not promised by Cargo / rustc / wasm-opt and isn't required by SEP-58. The check runs on the host runner's native arch against the smoke-built image for that arch.

Depends on

#4 (attest) — this branch is based on it. Base auto-updates to main once #4 merges.

Verification

Ran locally against stellar-cli:26.0.0-rust1.94.0. All three contracts produce stable hashes across two clean-target builds; token was verified twice — once against v23.0.0 and once against current main — and reproduced cleanly in both states (different content hashes, but stable across the double-build, which is the property we care about).

shellcheck clean on the new script. End-to-end behavior verifiable by opening this PR — the build workflow's new wasm reproducibility step should be green.

@fnando fnando requested a review from Copilot May 21, 2026 17:35
@fnando fnando self-assigned this May 21, 2026
@fnando fnando added this to DevX May 21, 2026
@github-project-automation github-project-automation Bot moved this to Backlog (Not Ready) in DevX May 21, 2026
@fnando fnando moved this from Backlog (Not Ready) to In Progress in DevX May 21, 2026
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a CI-time check to ensure WASM builds produced by the freshly built stellar-cli Docker image are reproducible (byte-identical outputs across repeated clean builds), using representative upstream Soroban example contracts.

Changes:

  • Introduces scripts/repro-test.sh to clone stellar/soroban-examples and run a double-build + hash comparison per contract.
  • Extends the build workflow to run the reproducibility check after the existing smoke test.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
scripts/repro-test.sh New repro test driver: clones examples repo, builds each contract twice in the image, compares produced WASM hashes.
.github/workflows/build.yml Adds a “wasm reproducibility” step to run the new script against the just-built local image.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread scripts/repro-test.sh
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

2 participants