Skip to content

Reproducible build attestation pipeline #19

@truthixify

Description

@truthixify

Labels: Stellar Wave, stellar, tooling, security, drips, help-wanted
Tier: L (1–2 weeks)
Type: tooling / security

Context

When we deploy wraith-names to Stellar mainnet, users need to be able to prove that the deployed Wasm hash matches the open-source code at a specific commit. Without a reproducible build, anyone could claim the deployed contract has a backdoor and we'd have no rebuttal.

This is the standard "binary attestation" problem solved by reproducible builds + signed manifests.

Scope

Set up contracts/stellar/build/:

  1. Pinned toolchainrust-toolchain.toml pinning the exact Rust version, target, and stellar-cli version used for builds.
  2. Dockerfile — a minimal container that:
    • Installs the pinned toolchain.
    • Builds each Soroban contract.
    • Optimizes via stellar contract optimize.
    • Produces a manifest attestation.json:
      {
        "commit": "<git sha>",
        "build_date": "2026-XX-XX",
        "toolchain": { "rust": "1.XX.X", "stellar-cli": "X.X.X" },
        "contracts": [
          { "name": "stealth-announcer", "wasm_sha256": "...", "wasm_size": 12345 }
        ]
      }
  3. CI pipeline that:
    • Runs the Docker build on every tag.
    • Publishes the attestation alongside the GitHub release.
    • Signs the attestation with a key controlled by the maintainer team (sigstore / cosign).
  4. Verification script — a one-liner anyone can run:
    pnpm verify:stellar-deployment --contract wraith-names --network mainnet --commit abc1234
    That fetches the deployed Wasm hash, fetches the published attestation for that commit, and verifies they match.

Constraints

  • Build must be deterministic: same commit + same toolchain → same hash. No build-time timestamps, no system path leakage, no Cargo random.
  • Verification script must work without network access to anything other than the Stellar RPC and GitHub releases.

Acceptance criteria

  • Reproducible Dockerfile committed.
  • CI publishing attestations.
  • Verification script + documentation.
  • One end-to-end demo: deploy to futurenet, publish attestation, verify offline.
  • Threat model written: what guarantees does this provide, and what does it NOT? (E.g., it doesn't protect against compromised signing keys.)

Why this matters

Trust in Wraith depends on "what's deployed = what's audited = what's open source." Without attestation, that chain is rhetoric, not proof. This is also a prerequisite for any future security audit firms — they will refuse to audit code they can't bind to a specific deployment.

Resources

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave programdripsFunded via Drips Networkhelp wantedExtra attention is neededsecuritySecurity-sensitive workstellarTouches Stellar / Soroban codetoolingBuild / tooling work

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions