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

Linux GNU kernel artifacts belong to the kernel release matrix, not the desktop installer matrix. Verify the embedded sidecar against the version-bound kernel bundle.

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.

What source, digest, and signature establish

The source commit identifies code; the build record identifies dependencies, toolchain, and target; the digest identifies exact bytes; signatures and platform validation establish publisher identity and platform acceptance conditions. Retain their relationship rather than substituting one result for the others.

A matching SHA-256 establishes that the retrieved file matches candidate bytes, not that its signing identity is correct. A valid signature does not establish the intended source commit. Verification must connect source, build job, signed artifact, and final download.

Scenario: a version needs rebuilding

Determine whether the repair concerns build environment, signing, or application code. Changed code needs an explicit new source. An unchanged version string does not make new bytes identical to the previously verified artifact. Re-signing or repackaging requires new digests and verification of the final file.

Do not overwrite an immutable published artifact. Preserve the failed record and create a traceable candidate through the owning repository's release process. State which evidence remains applicable and which checks were repeated so an old report cannot conceal a break in provenance.

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. Record the verified platforms in the candidate release. The public desktop update pointer waits for matching macOS architectures and Windows x64.

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.

Hand the candidate to verification

For each platform, provide the fixed source SHA, dependency and kernel-bundle versions, build job record, final installer location, size, SHA-256, and signature verification result. The candidate manifest must describe the final signed bytes. Repackaging or replacing a signed file requires new digests and verification.

A build, signing, or upload failure blocks delivery of that artifact and remains in the record. Use the owning repository's current release workflow for repairs rather than assembling generic signing commands from documentation. Completion means a verifier can retrieve the same artifact and independently check its source and signature.

Related pages

• Signed manifests
• Verify and promote

EvoX Docs · Developers · Software release maintenance