'No way to prevent this,' says only package manager where this regularly happens

Original Article ↗ Hacker News Discussion ↗

Satire & framing

  • Thread recognizes the title as a riff on The Onion’s “No Way to Prevent This…” series; some find it funny, others think applying the meme to security is in poor taste.
  • Several note this specific post closely resembles earlier similar parodies.

NPM vs other ecosystems

  • Many argue npm is uniquely bad due to postinstall scripts, lack of namespaces, and its culture, but others stress that PyPI, RubyGems, xz-utils, etc. show every ecosystem is vulnerable.
  • Some say Go/Rust are not inherently safer; they just have smaller or newer ecosystems and fewer dependencies.
  • Debate over whether Rust/cargo and Go modules are better: they also allow arbitrary code at build time (Rust build.rs, Go tooling), so the attack pattern exists there too.

Ecosystem & cultural factors

  • JavaScript criticized for:
    • Tiny standard library leading to heavy dependency use.
    • Culture of many small packages and frequent updates.
    • Large population of less-experienced developers and “move fast” norms.
  • Others point out Python has a robust stdlib yet still suffers, so stdlib size isn’t a complete explanation.
  • Complaints that core package infrastructure is underfunded relative to its importance.

Technical risk factors

  • High-risk features: npm postinstall scripts, unsandboxed build scripts/macros, access to CI secrets, lack of strict namespacing, range-based versioning, and huge transitive dependency graphs.
  • Lockfiles and pinning are seen as crucial; Python’s historic lack of a standardized lockfile is criticized.

Defensive strategies discussed

  • Use alternative JS package managers (pnpm, yarn, etc.), or even avoid npm/third-party deps where possible.
  • Cooldowns: delay installing very new releases by 1–7 days; claimed to have mitigated recent npm worms, but others say it only shifts attacks in time and relies on external scanners/maintainers to notice issues.
  • Namespaces tied to domain ownership (as in Maven Central) and immutable releases are praised, but domain cost and transfer are concerns.
  • Suggestions include: reproducible builds and signed attestations, private or proxied registries, nix sandboxes, vendorizing via git submodules/subtrees, company-wide “safe configs,” and global controls over postinstall execution.
  • Some see postinstall removal as essential; others call it a red herring because malicious code can run on import or at runtime anyway.