Package managers have an integrity problem

What it is

Trail of Bits' test of 25 source-code package managers against a compromised package repository that injects malware into legitimate packages. The post tells you which tools detect tampering by default, which only do so with extra configuration, and which cannot detect it at all. The harness is Docker plus a mitmproxy addon. The mitmproxy CA is installed in the image, so the addon can rewrite repository responses. Backend signing keys are assumed to stay secure.

Where defaults fail

• cpanminus uses plain HTTP by default, so any active network attacker can inject code. The official Perl Docker image patches it to use HTTPS. Its CHECKSUMS signature verification was removed after a bypass vulnerability.
• Lockfile hash present but not enforced:
• Pub installs on a hash mismatch unless --enforce-lockfile is passed. flutter run and flutter test call flutter pub get, so they can overwrite pubspec.lock unless called with --no-pub.
• pnpm overwrote the lockfile after a mismatch until version 11.4 (May 2026). Before that, --frozen-lockfile was needed.
• Lockfile hash not a content hash:
• Conan locks an MD5 recipe revision that it never recomputes, and the platform binary's package revision is not in the lockfile.
• CocoaPods locks a SHA-1 of the Podspec, not of the source fetched from GitHub.
• Composer locks a commit hash, but the ZIP archive it downloads from GitHub is not verified against it.
• No hashes or no lockfile:
• Gradle's gradle.lockfile and Gem's Gemfile.lock have no hashes. Gradle's verification-metadata.xml does have content hashes.
• Maven, R, PowerShellGet, PSResourceGet and cpanminus have no dedicated lockfile.
• pip (experimental pylock.toml), Conda (optional Conda lock) and NuGet (needs RestorePackagesWithLockFile) require opt-in.
• Hash-enforcing lockfiles by default: Bun, npm, pnpm, Yarn, uv, Poetry, Bundler, Cargo and SwiftPM. vcpkg ships hashes in its own source tree, which is secure as long as it is updated through git pull.

Signatures

Only Go verifies signatures by default. It checks module hashes against a checksum database (a transparency log) whose public key is hardcoded. This gives integrity with no hashes in go.mod. go.sum is only a local cache. The trade-off is that trust concentrates in one private key.

Everyone else needs configuration, or cannot verify at all:

What to do

• Check which row your package manager falls in. Where verification is off by default, turn it on: --enforce-lockfile (Pub), --frozen-lockfile (pnpm), NuGet require mode with trusted signers, and Gradle dependency verification or the Maven plugin.
• Commit lockfiles for applications. Libraries are less clear-cut. Many managers recommend committing for libraries (npm, pnpm, Poetry, uv, Yarn), Bundler recommends excluding, and Cargo leaves it to the developer.
• Hash-pinned lockfiles block immediate security updates, because a new release has a new hash. This forces frequent lockfile bumps.
• The proposed direction is for lockfiles to pin a signer identity or key plus a version or lower bound, backed by a transparency log, using Sigstore. pylock.toml, Gradle trusted-keys and pgp-keys-map.list already move this way.

Caveats

• Each manager was tested with one package, one version (the latest) and one platform (Ubuntu), including PowerShell and CocoaPods. The result shows a developer following reasonable conventions can be vulnerable, not that everyone is.
• System package managers (APT, Chocolatey, Homebrew) are out of scope.
• The vcpkg result excludes the question of securely updating vcpkg itself.
• SwiftPM was tested over Git. Its registry protocol supports signatures, but no public registry implements it.
• PowerShell on Windows was not tested. The documented default ExecutionPolicy would achieve integrity there.
• The hash-present-but-bypassable cases are documented behavior, not necessarily vulnerabilities.
• Repository signing does not help if the repository itself legitimately signs malicious code.