Cherry-pick of #11481 from main, adapted to the v10 layout.
For git-hosted tarballs (codeload.github.com / gitlab.com / bitbucket.org)
the fetcher dropped the integrity it computed while downloading, so the
lockfile only stored the URL. A compromised git host or man-in-the-middle
could serve a substituted tarball on subsequent installs and pnpm would
install it without lockfile changes.
This pins the SHA-512 SRI of the raw tarball in the lockfile in the same
sha512-<base64> form npm-registry tarballs use; subsequent installs verify
the download against that integrity in the worker.
A new optional gitHosted: boolean field is recorded on TarballResolution
so every store-key consumer can route by a single typed read instead of
re-deriving the routing from the URL. Lockfiles written by older pnpm
versions are enriched on load (URL fallback) so the field can be relied
on uniformly.
🤖 Cherry-picked by Claude (claude-opus-4-7) on behalf of @zkochan
* fix(git-fetcher): ensure the specified commit is used after checkout
* fix(git-resolver): always resolve to a full commit
* chore: add changeset heavy-dragons-start
* test: fix related test case
* test: fix some other test that gets stuck
* Update heavy-dragons-start.md with PR reference
Add reference to pull request #10310 for clarity.
* chore: `package.json` add type field
* chore: add type field to every package.json
* chore: add type field to every package.json
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
* fix(git-resolver): handle private git repo resolution
In the case where:
1. No git auth token was specified by the user
2. The package requested to be fetched via https
3. The user does not have SSH access to the repo but has HTTPS access
4. The package was hosted in a private GitHub repo
pnpm would fallback to using SSH since it was a "likely private repo"
and would fail to resolve the package. Now, rather than only checking if
there is an auth token specified, it also checks both:
1. Is the repo private
2. Does the user have access to ls-remote it.
And if these conditions are true, it tries to use https anyway.
This matches the behavior of npm and Yarn berry. Yarn classic also has
this bug, and there's a code comment that alludes to it.
