ReviewOS

home-lang/home

Enforce exact trusted-dependency identity and source rules

#643
Closed chris opened this 10 days ago ·
10 days ago

Problem

The unchanged full-VM lifecycle suite now exposes seven native installer trust-classification failures after dependency provisioning and manifest parsing are fixed:

  • --trust exits non-zero for an unhoisted untrusted package
  • a trusted dependency entry matches by a truncated hash instead of exact package name
  • a colliding package in the trusted subtree incorrectly runs its script
  • trust follows dependency aliases instead of the resolved package name
  • non-npm trust propagates beyond root/workspace declarations
  • binary-lockfile trust accepts a non-exact name match
  • default trust follows a non-canonical registry tarball URL

Several failures allow lifecycle scripts that pinned Bun blocks, so this is a correctness and supply-chain boundary rather than output-only parity.

Reproduction:

scripts/provision-corpus-deps.sh
HOME_NATIVE_VM=1 HOME_CORPUS_FULL_VM=1 ./zig-out/bin/home test packages/runtime/test/bun-corpus/cli/install/bun-install-lifecycle-scripts.test.ts

Current unchanged ReleaseFast file: 48 pass / 12 fail / 699 assertions. These seven are the trust identity/source subset.

Acceptance criteria

  • Trust decisions use the exact resolved package identity and full lockfile key.
  • Hash-prefix collisions, aliases, transitive non-npm packages, and non-canonical registry sources remain blocked exactly as in pinned Bun.
  • --trust handles unhoisted packages with the pinned exit/output behavior.
  • All seven unchanged cases pass in Debug and ReleaseFast.
  • No corpus edits, skipped scripts, weakened assertions, or broad trust fallback.

Related: #66, #518, #642.

10 days ago

Progress from 7774c52: routing the real native trust command also fixed the unhoisted-untrusted-scripts case. The unchanged lifecycle file now has six failures under this issue in both Debug and ReleaseFast: exact name vs truncated hash; trusted-subtree truncated-hash collision; resolved package name vs alias; non-npm trust restricted to root/workspace declarations; exact binary-lockfile name; and canonical registry tarball URL for default trust. Overall checkpoint: 54 pass, 6 fail, 758 assertions across 60 tests.

10 days ago

Resolved by df4dff8. Trust authorization now uses full PackageNameHash keys, npm aliases resolve to canonical package identity, non-npm trust is restricted to root/workspace declarations, default trust requires the exact canonical registry tarball URL, node-gyp inherits an already-proven trust decision, and binary lockfiles use a new 64-bit trust tag while legacy 32-bit records fail closed. Text lockfile serialization also preserves canonical npm names across aliases. Verification: unchanged lifecycle corpus 60/60 with 808 assertions in Debug and ReleaseFast; focused six security cases 6/6 with 77 assertions in both; runtime units 1,824 passed / 19 existing skips / 0 failed; Debug and ReleaseFast builds; formatting and diff checks; explicit Debug and ReleaseFast npm-alias lockfile round trips both confirmed canonical name present and alias absent. No corpus edits or weakened tests.

Sign in to comment on this issue.