Maybe you shouldn't install new software for a bit

Original Article ↗ Hacker News Discussion ↗

Recent Linux kernel privilege-escalation bugs and a wave of supply-chain attacks on package ecosystems like npm have prompted calls to temporarily avoid installing new software, especially on internet‑connected or build systems. Commenters debate whether delaying updates actually improves security, weighing the risk of rushed patches and compromised dependencies against the dangers of running unpatched code. Many advocate for more disciplined dependency management—pinning versions, using “cooldown” periods before adopting new releases, isolating builds in containers or VMs, and relying more on curated or BSD-style systems—to reduce the blast radius of inevitable vulnerabilities.

Kernel LPEs, disclosure, and immediate risk

  • Thread revolves around recent Linux local-privilege-escalation bugs (Copy Fail / Dirty Frag / variants).
  • Confusion over disclosure: some think embargo was broken; links show third parties derived exploits from public patches.
  • Debate on responsible disclosure: seen as a “gentleman’s agreement” under strain from low bounties and AI‑generated low‑quality reports.
  • Several note that if fixes are public, LLMs can help reverse patches and generate exploits faster.

“Don’t install new software” and supply-chain attacks

  • OP’s advice is read as: short, one‑time moratorium on installing new software while kernel vulns are unpatched, especially via npm.
  • Rationale: a compromised npm package could chain the LPE to get root on many systems (dev machines, CI, servers).
  • Some call this FUD or “attacker logic” (“don’t update your systems”), arguing unpatched old software is a bigger risk.
  • Others think the advice is narrowly reasonable for this particular week, not as a general practice.

Dependency management & cooldowns

  • Strong concern about npm/PyPI/Cargo attacks via account compromise and malicious releases.
  • Proposed mitigations:
    • “Cooldowns”: only allow package versions older than X days; let others be the beta testers.
    • Corporate artifact repositories / allow‑lists (e.g. artifact managers, internal mirrors).
    • Pin exact versions and use lockfiles correctly (npm ci, --frozen-lockfile).
    • PR guards that forbid unpinned or lockfile‑mismatched deps.
  • Critiques:
    • Cooldowns can delay real security fixes.
    • Attackers can just wait out the cooldown or label malware as “security updates.”
    • Reviewing all transitive deps is often infeasible; many “curated” repos mostly bump versions and hashes.

OS choices and security postures

  • Some advocate BSDs (especially FreeBSD, OpenBSD) for more coordinated security handling and faster binary updates.
  • Pushback notes gaps like late ASLR adoption, missing kASLR, past incidents (e.g., buggy WireGuard import), and weak defaults.
  • Microkernels and capability systems (e.g., seL4) discussed as structurally safer, but others argue they don’t inherently stop logic bugs in critical components like filesystems.

Sandboxing, containers, and practices

  • Many recommend isolating risky tooling (npm, pip, gem, etc.) in containers/VMs; avoid installing such tools on the host.
  • Examples: Docker, Kata, Qubes OS, macOS firewalls (e.g., LuLu), disabling kernel modules (esp4/esp6/rxrpc) as temporary mitigations.
  • Consensus that user‑space compromise plus easy sudo use is already near‑“game over”; proper isolation and minimal privileges matter more.

Broader reflections

  • Widespread sense that:
    • Package ecosystems and “curl | sh” norms have created enormous attack surfaces.
    • AI accelerates both vulnerability discovery and “slopcode” generation.
    • Open source’s economic model (heavy corporate dependence, light maintainer support) is under serious strain.