Verify a release yourself

You do not have to trust us. This page is the recipe for confirming, yourself, that a downpipes release is exactly what it claims to be: built by CI from a specific tagged commit, and byte-identical from that build through the channel to what your account applied. The product does all of this automatically at apply time; this page is for the security team that wants to re-derive every step independently.

What this proves, and what it does not

It proves that the bundle your engine applied is byte-for-byte the artefact CI built from the tagged source, that the build is repeatable by anyone from that same source, and that the platform held exactly those bytes at the moment your account promoted them.

It does not prove the source is benign. A defect or a backdoor written into the source would reproduce perfectly. Source review, under whatever source-access arrangement applies to your engagement, is the separate assurance that covers that; reproducibility and source review are different guarantees and we keep them distinct.

It does not prove real-time runtime execution. Cloudflare Workers, like every serverless platform, exposes no hardware attestation of the code running at a given instant. Your engine verifies the bytes at apply time, records the verdict in your own hash-chained audit trail, and re-compares the running deployment’s version identity against the last verified apply on every Security Centre evaluation (the update-version-drift check). Between those checks you are trusting the Cloudflare control plane and whoever holds access to your own account, which is the same trust every Worker in your account already carries. We state that boundary plainly rather than imply more; established reproducible-build projects such as Tor state the same one.

Step 1: rebuild the artefact from source

The release artefact is a deterministic function of the tagged source: the same commit with its lockfile-pinned toolchain produces the same bytes wherever it is built. A CI workflow re-proves this on every change to the build inputs and on a weekly schedule, building twice on the two runner images we test, from two working paths, and failing on any drift. This step needs source access, which is part of your engagement’s source-access arrangement.

git clone <the engine repository> && cd engine
git checkout vX.Y.Z
npm ci
node scripts/build-release.mjs
# prints { version, sha384, sha256, ... } and writes dist/engine-X.Y.Z.mjs

The sha384 printed here is the value to carry through every later step. The build refuses to run on a dirty tree or a stamped build-stamp.ts, so what you build is a function of the commit alone. Without source access, start at step 2: everything from the signed channel onward verifies with public material alone.

Step 2: compare against the signed channel

The channel document your engine verifies is public. Fetch it and confirm the digest matches your rebuild:

curl -fsSL https://update.downpipes.io/stable.json
# components.engine.sha384 must equal your rebuilt sha384

The channel is signed with the pinned post-quantum hybrid key (Ed25519 plus ML-DSA-87, both halves required); your engine refuses any channel that does not verify under the pin your account holds. The provenance block inside the same signed body names the source commit, the release tag, the CI run and the Rekor transparency-log index, so the offline release key vouches for those pointers too.

Step 3: verify the CI attestations

Every attestation file is republished on the channel host, so this step needs no access to our repositories:

BASE=https://update.downpipes.io/provenance/X.Y.Z
curl -fsSLO $BASE/engine.intoto.jsonl
curl -fsSLO $BASE/engine-X.Y.Z.mjs.cosign-bundle
curl -fsSLO $BASE/engine.SHA256SUMS.txt
curl -fsSLO $BASE/release-record.json

cosign verify-blob --bundle engine-X.Y.Z.mjs.cosign-bundle \
  --certificate-identity-regexp '^https://github.com/downpipes/engine/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  dist/engine-X.Y.Z.mjs

slsa-verifier verify-artifact dist/engine-X.Y.Z.mjs \
  --provenance-path engine.intoto.jsonl \
  --source-uri github.com/downpipes/engine

The cosign identity pin means the signature is valid only if it was minted by the engine repository’s release workflow on a version tag; the keyless certificate and the signature are logged in the public Sigstore Rekor transparency log, so a signature served to you and hidden from everyone else is detectable.

Step 4: read your own account’s record

This is the step no vendor can do for you, and no vendor can fake after the fact. Open the console’s Licence and updates screen, Provenance section. It shows, from your engine’s own persisted records:

• the apply-time evidence: the signed digest your engine enforced at the last apply (recorded at promote time; the settled record and the hash-chained audit log both carry it) and the platform read-back verdict, whether Cloudflare’s own API returned byte-exactly those bytes before your account promoted them;
• an on-demand cross-check of your recorded digest against the published release record.

The Security Centre adds two standing checks: update-apply-provenance (the last apply left durable content-hash evidence) and update-version-drift (the running deployment is still the one the last verified apply left live; any out-of-band redeploy flips it). Both also ride into the signed evidence packs where a framework maps them: the drift check evidences ISO/IEC 27001 A.8.16 (monitoring activities), and the provenance check evidences NIS2 Article 21(2)(d) (supply chain security).

If any step fails

A mismatch at any step is exactly what this process exists to surface. Check first that you compared the same version (the channel moves; your account’s record names the version it applied). If the versions match and the digests do not, treat it as an incident: contact security@maelstrom.au, and keep the artefacts you fetched.

Last updated 5 July 2026.