Skip to content

fix(install): verify release archive checksum before install#38

Open
hobostay wants to merge 1 commit into
Tencent:mainfrom
hobostay:fix/installer-verify-checksum
Open

fix(install): verify release archive checksum before install#38
hobostay wants to merge 1 commit into
Tencent:mainfrom
hobostay:fix/installer-verify-checksum

Conversation

@hobostay

Copy link
Copy Markdown

Problem

The first-run installers (install.sh, install.ps1) downloaded and extracted the bsk release archive with no integrity check, even though the in-app bsk update path treats a sha256 checksum as mandatory:

crates/bsk-cli/src/cli/update.rs"release … does not include a sha256 checksum; cannot safely auto-update" and then verify_sha256(...).

A compromised release artifact, CDN, or cache delivers a trojaned bsk binary and the installer installs it as-is. The release version.json already carries a per-asset sha256 (scripts/render-version-json.mjs renders it with --dist), so the installers can verify exactly the way bsk update does.

Change

Both installers now fetch version.json once (for both pinned BSK_VERSION and latest), read assets[<platform>].sha256, and verify the downloaded archive's sha256 before extracting:

  • install.sh — POSIX sed parses the per-platform field (no jq dependency, matching the existing sed-based version parse); sha256sum / shasum -a 256 computes the digest.
  • install.ps1Invoke-RestMethod parses the JSON and Get-FileHash -Algorithm SHA256 computes the digest; comparison is case-insensitive (-ieq).

Failure handling:

  • Checksum mismatch → fatal (fail-closed, matching bsk update).
  • Missing manifest / no published checksum / no sha256 tool → skip with a warning. This keeps the first-run bootstrap working on minimal or offline machines instead of hard-failing a legitimate install.

This preserves install behavior while closing the integrity gap the updater already enforces.

Validation

The installers are not exercised by CI (no shell/PowerShell test harness), so validated manually:

  • sh -n / bash -n on install.sh (clean).
  • Functional test of extract_asset_sha256 against a realistic pretty-printed version.json (correct per-platform hash; empty → skip for an absent platform) and of compute_sha256 against sha256sum (matching digest).
  • install.ps1 reviewed for PS 5.1 compatibility (Get-FileHash, dynamic member access $manifest.assets.$platformKey.sha256, -ieq).

version.json schema is unchanged (only consumed), so the node-scripts CI job is unaffected.

🤖 Generated with Claude Code

The first-run installers (install.sh, install.ps1) downloaded and
extracted the bsk release archive with no integrity check, even though
the in-app `bsk update` path treats a sha256 checksum as mandatory
(update.rs bails with "does not include a sha256 checksum; cannot
safely auto-update"). The release version.json already carries a
per-asset sha256 (render-version-json.mjs renders with --dist), so the
installers can verify the same way.

Both installers now fetch version.json once (pinned and latest), read
`assets[<platform>].sha256`, and verify the downloaded archive's sha256
before extracting:
- install.sh: POSIX sed to parse the field (no jq dependency), and
  sha256sum/shasum to compute the digest.
- install.ps1: Invoke-RestMethod + Get-FileHash.

A checksum mismatch is fatal (fail-closed, matching `bsk update`). A
missing manifest/checksum, or the absence of a sha256 tool, only skips
verification with a warning, so the first-run bootstrap still works on
minimal/offline machines.

Validation: `sh -n` / `bash -n`; functional test of the sed extraction
against a realistic version.json and of compute_sha256 against
sha256sum. The installers are not exercised by CI (no shell harness).

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant