Repository navigation
Self-update and install.sh trust an unsigned SHA256SUMS from the same release #1065
Description
[agent] Filed by the October 7 architecture audit campaign (core). Register: arch-audit register.
Kind: bug. Source: audit B67 (new finding), register C72.
Problem: self-update (update/download.rs, release::fetch_sha256sums_entry) and scripts/install.sh check the archive only against a SHA256SUMS fetched from the same release. No workflow publishes a signature or attestation for the standalone binaries (no attest-build-provenance, cosign or minisign); only npm and crates get registry provenance. Immutable releases stop an existing release's assets from being swapped, but a leaked contents:write token or a compromised release job can publish a new higher version with a matching SHA256SUMS, and --update and curl | sh follow latest.
Impact: the updater of a supply-chain security product trusts a single unsigned origin.
Proposed change: publish GitHub artifact attestations (or a minisign signature over SHA256SUMS) in the release workflow, and verify it in update/download.rs against a key or identity embedded at build time, and in install.sh when the tooling is present.
Acceptance criteria:
- Release assets carry an attestation or signature.
-
--updaterefuses an archive whose signature does not verify; a test covers it.
Dependencies: #983's decision (keep and harden the --update swap). Release workflows are maintainer-owned.
Generated by Claude Code
Activity
mikolalysenko commentedon Oct 7, 2026
[agent] Triage: priority:p3 (CLI/release). Needs a maintainer: the fix requires changing the release workflow to publish signatures or attestations, which is maintainer-owned and outside what the agent may touch. Labelled agent:needs-human.
Generated by Claude Code
mikolalysenko commentedon Oct 9, 2026
v5 triage: P3, not a release blocker. Release signing/provenance is separate security engineering work; no demonstrated first-run compatibility regression here. Retain P3, outside this release triage scope.
This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX.
mikolalysenko commentedon Oct 9, 2026
This is a bigger project. We need to figure out where to store the key material and do the signing. Ideally this should happen within Socket's internal deployment but setting this up could take a while. If we get extra help we could begin that project, but the current situation is ok for now.