Build and sign

EvoX Desktop, Linux artifacts, the embedded sidecar, the Evolver npm package, and the documentation website use different pipelines. A successful build of one object does not validate the artifacts or signatures of another.

Current platform artifacts

Build record

Every artifact should trace back to:

source repository and revision
release version and channel
build environment and toolchain
target platform / architecture
artifact filename and size
SHA-256
signature identity and verification method

Signing boundary

Signing keys belong only in the owning release system, not repositories, ordinary logs, build caches, or documentation. Separate builder and final promoter where possible; at minimum, use a second person or independent pipeline to verify downloaded bytes and signatures.

Build order

1. Pin the source revision, dependency locks, and toolchain.
2. Build per platform instead of inferring one platform from another.
3. Sign and produce candidate manifest data.
4. Upload immutable artifacts and hand them to an independent re-download verification step.
5. Update the public manifest only after every required target passes.

Separate release objects

A documentation deployment proves only that the website changed; it does not build or validate an EvoX installer. Publishing the Evolver npm package also does not update Desktop or the sidecar. Track object, repository, version, and owner separately.

Related pages

• Signed manifests
• Verify and promote

EvoX Docs · Administration · Release management