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

Original Article ↗ Hacker News Discussion ↗

Repeated supply-chain attacks on the npm JavaScript package ecosystem are prompting renewed criticism of its design, especially the ability for packages to run arbitrary “postinstall” scripts and the culture of pulling in vast webs of tiny dependencies. Commenters compare npm with other ecosystems like PyPI, Cargo, Maven and Linux distro package managers, arguing that features such as namespaces, stricter publishing controls, cooldown periods for new releases, and sandboxed or reproducible builds would significantly reduce risk. Others stress that any modern package manager is vulnerable if developers routinely execute unvetted third‑party code, and that deeper cultural and funding issues in open source make comprehensive fixes hard to sustain.

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.