[MEDIUM] No integrity hash on the @percolator/shared git-tarball dependency in pnpm-lock.yaml

[Morenikeoa]

Summary

pnpm-lock.yaml pins @percolator/shared to a GitHub-tarball URL at a specific commit SHA, but — unlike every npm-registry-sourced dependency in the same lockfile — has no integrity hash recorded for it. There's nothing stopping a silent content change at that pinned commit from being installed without detection.

Evidence

# pnpm-lock.yaml:453-457
'@percolatorct/shared@https://codeload.github.com/dcccrypto/percolator-shared/tar.gz/489f5b48b6d7826ce62bae6734bb3d078c392730':
  resolution: {tarball: https://codeload.github.com/dcccrypto/percolator-shared/tar.gz/489f5b48b6d7826ce62bae6734bb3d078c392730}
  version: 1.0.0-beta.8
  peerDependencies:
    '@percolatorct/sdk': '>=2.0.5'

Compare to a normal npm-registry dependency a few lines later in the same file:

# pnpm-lock.yaml:459-460
'@prisma/instrumentation@7.2.0':
  resolution: {integrity: sha512-Rh9Z4x5kEj1OdARd7U18AtVrnL6rmLSI0qYShaB4W7Wx5BKbgzndWF+QnuzMb7GLfVdlT5aYCXoPQVYuYtVu0g==}

Only the tarball: URL is recorded for @percolator/shared, with no integrity: field at all.

Impact

If the commit at 489f5b48b6d7826ce62bae6734bb3d078c392730 were ever rewritten upstream (force-push, history rewrite, or a compromised/compelled push to dcccrypto/percolator-shared), or if GitHub's on-the-fly tarball generation ever produced different bytes for that same SHA, pnpm install would silently install different code with no hash mismatch to catch it. This is the supply-chain integrity guarantee that integrity: hashes exist to provide, and it's currently absent for this dependency.

Why this isn't a straightforward code fix

This turns out to be an inherent limitation of how pnpm (and npm) handle git/tarball-URL dependencies generally — pnpm-lock.yaml records an integrity hash for content-addressed registry packages but does not synthesize one for arbitrary tarball URLs the way it would for an npm-registry resolution. There's no lockfile-only fix; closing this gap would require either:

• Vendoring @percolator/shared via a real npm registry (private or public) with proper integrity hashes instead of a github: dependency spec, or
• Pinning and manually verifying a integrity/checksum field via pnpm's overrides/packageExtensions if pnpm's tooling supports attaching one to a tarball dependency (would need verification — not confirmed to work for this dependency type), or
• Accepting the residual risk and relying on the commit-SHA pin alone as the primary integrity control (the current de facto posture).

Filing this as a known architectural tradeoff worth a deliberate decision rather than attempting a low-value/incorrect lockfile edit.

Found via

Phase 4 of a structured multi-agent security/correctness audit against the v17 branch (main). Confirmed independently by 3 auditors; not fixed because no actionable code-level remedy exists within this repo.