mirror of
https://github.com/oven-sh/bun
synced 2026-02-27 03:57:23 +01:00
ede635b8a9
## Summary - HTTPS/URL tarball dependencies were not having their integrity hash stored in the lockfile, allowing a malicious server to change the tarball contents without detection on subsequent installs - Now computes a sha512 hash from the downloaded tarball bytes during extraction and stores it in both the binary lockfile and text bun.lock - The hash is verified on re-download, matching the behavior of npm registry packages - Old lockfiles without integrity hashes continue to work (backward compatible) ## Changes - `src/install/integrity.zig`: Added `Integrity.forBytes()` to compute sha512 from raw bytes - `src/install/install.zig`: Added `integrity` field to `ExtractData` struct - `src/install/PackageManagerTask.zig`: Compute hash from tarball bytes for both remote and local tarball tasks - `src/install/PackageManager/processDependencyList.zig`: Set `package.meta.integrity` from computed hash - `src/install/lockfile/bun.lock.zig`: Serialize/deserialize integrity for `remote_tarball` and `local_tarball` types ## Test plan - [x] Integrity hash is stored in text lockfile for tarball URL deps - [x] Integrity hash is consistent/deterministic across reinstalls - [x] Integrity mismatch (changed tarball content) causes install failure - [x] Old lockfiles without integrity still install successfully (backward compat) - [x] Fresh installs produce integrity hashes - [x] All 12 existing tarball tests pass (no regressions) - [x] Tests fail with `USE_SYSTEM_BUN=1` (confirms fix is effective) Fixes GHSA-jfhr-4v9p-9rm4 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Bot <claude-bot@bun.sh> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>