fix(resolver): pin hosted git tarball integrity#783
Conversation
Greptile SummaryThis PR adds optional SHA-512 SRI pinning for hosted codeload git tarballs: the resolver computes and writes integrity to the lockfile on first fetch, subsequent runs verify the pinned value before extraction, and the codeload cache key now incorporates integrity when present. Only the pnpm backend round-trips the field; bun, npm, and yarn parsers hard-code
Confidence Score: 5/5Safe to merge — integrity verification is additive and the existing git-clone fallback is untouched. All changed paths are well-scoped to the codeload fast path. The integrity field is optional throughout, so existing lockfiles without it degrade gracefully. The resolver correctly persists computed integrity to the lockfile, and both the resolver and install paths verify pinned values before extraction. Cache key changes are backward-compatible. No files require special attention. Important Files Changed
Reviews (2): Last reviewed commit: "fix(resolver): avoid redundant codeload ..." | Re-trigger Greptile |
|
Addressed the review feedback by verifying codeload bytes only when a lockfile-pinned integrity exists. First-time codeload fetches now compute the SHA-512 pin for persistence/cache keying without immediately re-verifying against itself. Validated with:
This comment was generated by Codex. |
Summary
Test plan
Note
Medium Risk
Changes fetch/verify/cache behavior for git codeload dependencies; wrong integrity handling could break installs or cache hits, but scope is limited to the codeload fast path with new tests.
Overview
Adds optional SHA-512 SRI on
GitSourcefor hosted codeload git tarballs (not plaingit clone), wired through pnpm lockfile read/write andLockedPackage.integrity.Resolver and install fetch now verify downloaded codeload bytes against a pinned integrity when present, otherwise compute SRI via new
sha512_integrity, persist it on the git source, and pass integrity into extract / cache lookup. Codeload cache keys mix in integrity when set so different tarball hashes do not share a directory; cache reuse on the fast path only runs when integrity is already known.Other lockfile backends (bun, npm, yarn) initialize
integrity: Noneon git sources. Minor test/style tweaks (is_none_or,contains_key) are unrelated.Reviewed by Cursor Bugbot for commit 7a80a54. Bugbot is set up for automated code reviews on this repo. Configure here.