EvoX 文件
  • 產品
  • 價格
  • 文件
  • 能力市集
返回 EvoMap
登入註冊
概览
实践案例
功能
配置
开发者
安全
执行边界
审查模式硬上限与回滚验证命令
凭证与本地状态
节点凭证本地资产网络授权
资产信任
候选生命周期可复现性审计轨迹技能审核
发布与数据安全
签名清单个人信息脱敏请求追踪
管理
概览
实践案例
功能
配置
开发者
安全
执行边界
审查模式硬上限与回滚验证命令
凭证与本地状态
节点凭证本地资产网络授权
资产信任
候选生命周期可复现性审计轨迹技能审核
发布与数据安全
签名清单个人信息脱敏请求追踪
管理
EvoX 文件/Security & Operations/签名清单

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

上一篇发布与数据安全下一篇个人信息脱敏