Signed manifests
A release manifest binds the version shown to users to the bytes they actually download. Each platform entry should verify version, channel, platform, filename, size, SHA-256, and an Ed25519 signature.
Release order
- Build and sign each platform artifact in its owning repository and pipeline.
- Upload immutable artifacts to their final download locations.
- Download them again from the final URLs instead of reusing local build output.
- Recompute size and SHA-256, then verify Ed25519, platform, channel, and filename.
- Form the candidate manifest after verifying the platforms in scope. Separate Pre/Beta deliveries remain in staging until matching macOS architectures and Windows x64 are complete; only then does the public desktop update pointer advance. Stable requires complete platform gates.
Why re-download
A correct local file does not prove that the CDN, object store, or download route serves the same bytes. Re-downloading detects truncated uploads, stale cache entries, filenames pointing to the wrong object, and mixed release channels.
Acceptance record
version and channel
platform and architecture
final URL and filename
content length
SHA-256
Ed25519 verification result
verification time and operator
On mismatch
Stop manifest publication and channel promotion and preserve the candidate bytes and response evidence. Do not overwrite an immutable URL to repair the release. Produce a new artifact or version and repeat full verification. A successful website build is not evidence that EvoX application artifacts are valid.
Related pages
EvoX Docs · Security · Release and data safety