Record integrity hashes for the four @buf lockfile entries - #143
jamesarich wants to merge 1 commit into
Conversation
The @buf packages resolve through buf.build's npm registry, whose packument carries only a tarball URL - its `dist` has no `integrity` and no `shasum`. pnpm 8, which wrote these entries, took that at face value and recorded no hash. pnpm 10 turned a missing hash from a warning into a hard error, so any install on pnpm 10 or 11 fails against this lockfile: pnpm 11.25.0 ERR the lockfile contains entries that the active policies reject (all four named) pnpm 10.34.4 ERR ERR_PNPM_MISSING_TARBALL_INTEGRITY pnpm 9.15.9 ok - which is why CI is green; it pins 9 Newer pnpm computes the hash from the downloaded tarball, but only on a fresh resolution: it will not reuse an entry it has already rejected, so `--no-frozen-lockfile` does not repair it and a full regeneration would move every unrelated dependency at the same time. So write just the hashes. Each is the sha512 of the tarball buf.build serves today, which is byte-identical to what pnpm 11 computes when it resolves these packages from scratch. No version changes, no resolution changes. Verified against all three majors with the repo's own steps - `pnpm install --ignore-scripts=false`, `pnpm build` (dist/index.js emitted), and `pnpm validate:maintenance-uf2`. The lockfile is byte-stable after each.
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Fixes #142.
pnpm installfails on any pnpm newer than 9, because the four@bufentries inpnpm-lock.yamlcarry nointegrityhash. CI does not catch it:pnpm/action-setupis pinned toversion: 9.buf.build's registry generates tarballs on demand and its packument has only a tarball URL — no
integrity, noshasum— so pnpm 8 recorded nothing when it wrote these entries. pnpm 10 made that a hard error.What this changes
Four lines. The existing
resolution: {tarball: ...}gains anintegrity:; nothing else moves.No version changes, no resolution changes, no
package.jsonchange. In particular this does not touch thepnpmdevDependency — that is dependabot's #101 and is unrelated to what actually resolves the install.Where the hashes come from
Each is the sha512 of the tarball buf.build serves for that exact version. They are byte-identical to what pnpm 11 computes when it resolves these packages from a fresh lockfile, which is the mechanism newer pnpm uses for registries that cannot supply a hash:
Regenerating the lockfile instead would also work, but it moves every unrelated dependency in the same commit (
wrangler,yaml,@bufbuild/protobuf1.7.2 → 1.10.1, …), which is a much harder diff to review for a supply-chain fix.--no-frozen-lockfiledoes not work at all: pnpm will not reuse an entry it has already rejected.Testing
Installed against all three majors with
--frozen-lockfile, and the lockfile is byte-stable after each:ERR_PNPM_MISSING_TARBALL_INTEGRITYLockfile passes supply-chain policies (358 entries)Then the repo's own CI steps on pnpm 9 / Node 22:
pnpm install --ignore-scripts=false— okpnpm build— ok,dist/index.jsemittedpnpm validate:maintenance-uf2— ok,4 erase image(s), 19 OTAFIX board(s), 17 supported target(s)Draft because the hashes pin what buf.build serves today; worth a second pair of eyes on that being the intent before it merges.