Hardening: sign native installer manifests and release provenance

Summary

Migrated/adapted from MoonshotAI/kimi-cli#2273 for Kimi Code CLI, but updated for the current Kimi Code installer design.

The old kimi-cli issue described a Python tarball updater without checksum verification. Kimi Code is different: the current native installers fetch a per-version manifest and verify SHA-256 before installing the platform binary.

This issue is therefore not claiming that Kimi Code lacks checksums. The remaining hardening opportunity is release provenance: make the manifest/checksum itself independently verifiable, not only fetched from the same distribution channel as the binary.

Proposed hardening

Consider one of these release-chain improvements:

• Publish a signed manifest for each release version.
• Verify the manifest signature in install.sh and install.ps1 before trusting filenames/checksums.
• Publish provenance/attestations for native binaries, for example through Sigstore/cosign or an equivalent release signing flow.
• Document the expected trust model for CDN-hosted native installers.

Why it matters

Checksum verification protects against corrupted or mismatched binaries. Signed manifests/provenance add another layer: users and enterprise environments can verify that the artifact came from the expected release process, not only that it matches a checksum served from the distribution endpoint.

This is especially useful for a terminal AI agent because installers and auto-updaters are high-trust code paths.

Related

• Original kimi-cli hardening issue: https://github.com/MoonshotAI/kimi-cli/issues/2273
• Current installer entrypoints:
  • https://code.kimi.com/kimi-code/install.sh
  • https://code.kimi.com/kimi-code/install.ps1

Start by reviewing the current installer entrypoints at code.kimi.com/kimi-code/install.sh and install.ps1, then compare their manifest and SHA-256 verification flow with the proposed release-chain options. The issue does not select a signing or provenance approach, so first define the trust model and implementation scope. Done means the chosen verification flow is implemented for both installers and documented for users.