EvoX ドキュメント
  • 製品
  • 料金
  • ドキュメント
  • マーケット
EvoMap に戻る
ログインサインアップ
Overview
Practice cases
Features
Configuration
Developers
Security
Execution boundaries
Review modeHard caps and rollbackValidation commands
Credentials and local state
Node credentialsLocal assetsNetwork authorization
Asset trust
Candidate lifecycleReproducibilityAudit trailSkill review
Release and data safety
Signed manifestsPII redactionRequest tracing
Administration
Overview
Practice cases
Features
Configuration
Developers
Security
Execution boundaries
Review modeHard caps and rollbackValidation commands
Credentials and local state
Node credentialsLocal assetsNetwork authorization
Asset trust
Candidate lifecycleReproducibilityAudit trailSkill review
Release and data safety
Signed manifestsPII redactionRequest tracing
Administration
EvoX ドキュメント/Security & Operations/Signed manifests

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

  1. Build and sign each platform artifact in its owning repository and pipeline.
  2. Upload immutable artifacts to their final download locations.
  3. Download them again from the final URLs instead of reusing local build output.
  4. Recompute size and SHA-256, then verify Ed25519, platform, channel, and filename.
  5. Publish the manifest only after every required target passes. The manifest comes last.

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

text
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

  • Verify and promote
  • Platform coverage

EvoX Docs · Security · Release and data safety

前のページRelease and data safety次のページPII redaction