5 ms·

‘No way to prevent this’, Says Only Development Community Where This Regularly Happens ­— <https://itnext.io/no-way-to-prevent-this-says-only-development-commu

• deleted 5mo ago
  [deleted]
• anonym29 5mo ago
  "A well administered supply chain, being necessary to the freedom of an open internet, the right of the developers to keep and bear hundreds of uninspected transitive dependencies, shall not be infringed."
• ajross 5mo ago
  The Node ecosystem happens to be more vulnerable for social and software design reasons, it's true. But people need to be aware that PyPI and Cargo et. al. are not in any fundamental way less vulnerable. This will happen there too.
  • zarzavat 5mo ago
    To expand on this, PyPI is slightly less vulnerable because Python users tend to install mega packages (such as numpy or django) and do not frequently interact with their package manager. There is also not a culture of using sub-dependencies. Cargo is essentially the same as NPM though, it's only "safer" because it's less popular. Although the situation on NPM is extremely uncomfortable, you're probably less likely to get hit if you take reasonable precautions than on PyPI, simply because NPM is getting scanned more often. Most of these attacks on NPM have been detected and pulled days before my min age kicks in. A sleeper attack on PyPI could be devastating.
  • zahlman 5mo ago
    In fact, attacks like Shai-Hulud explicitly attempt to get into PyPI, and have succeeded to a lesser extent. But aside from the package-size / -complexity issue pointed out in a sibling comment, PyPI also tries a fair bit to monitor for incoming malware (and there's a "report project as malware" button on each project page). Also, there are no post-install scripts (of course, the code can detect when it's being run for the first time in the installed environment); and pre-install scripts are only included in sdists[0]. So you can easily[1] configure your installer such that you at least won't get pwned at install time, at the cost that some[2] packages can't be installed that way. And then you can go inspect, run a security scanner over, etc. whatever got installed; wheel installations just copy things to well-defined locations and generate simple wrapper scripts by strict rules. [0]: I.e., when the project is "being built from source", which generally is only necessary when it includes non-Python code directly and the maintainer hasn't pre-built that code for your system. [1]: Notwithstanding that, with pip, many actions that you'd expect not to get you pwned totally can. Such as, for example, explicitly telling it to download an sdist and not install it; as I discussed in https://zahlman.github.io/posts/python-packaging-3/ https://zahlman.github.io/posts/python-packaging-3/ . [2]: In practice, a pretty small fraction of what typical developers would actually care about, at least outside of specific niches. I'm told there are some niches where it's a big problem, but honestly they're lucky that this kind of build-install orchestration sort-of works at all.
• fennecbutt 5mo ago
  Isn't this more like a "Macs don't have viruses" type scenario though?
  • pletnes 5mo ago
    I thought it was «windows has all the viruses» since there are a lot of npm packages and it’s used by a lot of people?
• mschuster91 5mo ago
  > Says Only Development Community Where This Regularly Happens We've had such issues on other places as well... Shai-Hulud got into Maven [1] and PHP Composer [2], typosquatters got into Maven [3], and it's not new either [4]. No one is safe from skiddies, much less from nation state actors. [1] https://thehackernews.com/2025/11/shai-hulud-v2-campaign-spreads-from-npm.html https://thehackernews.com/2025/11/shai-hulud-v2-campaign-spr... [2] https://semgrep.dev/blog/2026/malicious-intercom-php-package-spreads-mini-shai-hulud-attack-to-packagist-via-composer-plugin/ https://semgrep.dev/blog/2026/malicious-intercom-php-package... [3] https://www.esecurityplanet.com/threats/malicious-jackson-lookalike-library-slips-into-maven-central/ https://www.esecurityplanet.com/threats/malicious-jackson-lo... [4] https://socket.dev/blog/malicious-maven-package-exfiltrates-oauth-credentials https://socket.dev/blog/malicious-maven-package-exfiltrates-...
  • gred 5mo ago
    Your example of security issues in Maven is... npm guys setting up processes to auto-publish infected npm packages into the Maven Central repository? Wake me up when the daily npm security breach headlines are typosquatting stories, not RCE-on-build or RCE-on-upgrade.
    • mschuster91 5mo ago
      > Wake me up when the daily npm security breach headlines are typosquatting stories, not RCE-on-build or RCE-on-upgrade. RCE-on-build/upgrade can be done in Maven if you manage to compromise one of the major Maven plugins, they run at build time. The thing keeping maven safe for now is that most people pin the plugin and dependency versions, with the obvious side effect that it's truly annoying to get all your dependencies updated.
      • gred 5mo ago
        > The thing keeping maven safe for now is that most people pin [...] versions Yes, and also the signing of JARs that are uploaded to the repository, and the fact that most release processes are not fully automated, and the batteries-included standard library which reduces the total number of dependencies, and the fact that a run-of-the-mill third-party library can't execute code at build time, and the very small number of people with credentials to publish new versions of major Maven plugins, etc.
• jubilanti 5mo ago
  Yeah funny, but npm is not the only development community where this regularly happens. The Onion article this joke refers to [1] is funny because there is a very clear and obvious reason why the U.S. has far more gun deaths per capita. This doesn't apply for npm. [1] https://theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1848971668/ https://theonion.com/no-way-to-prevent-this-says-only-nation...
  • throwaway27448 5mo ago
    Oh? Edit: please explain. What other community has this rate of attacks? It's possible they are just detected or publicized less, too. Please help me understand what you're referring to.
    • Yokohiii 5mo ago
      I'd also like to know who monitors the casualties.
    • shoeb00m 5mo ago
      some Pipy packages were also attacked recently. And is even more vulnerable due to many projects using requirements.txt which doesn’t lock sub dependencies
      • OhMeadhbh 5mo ago
        Sure, but the Python community isn't the paragon of software risk management excellence you may think it is. Both Python and Node users (metaphorically) asked for a loaded revolver... They got a metaphorical high yield thermonuclear device with a large blast radius. (And then they skipped the safety tutorial for the B-83 they just bought.)
  • deleted 5mo ago
    [deleted]
  • woodruffw 5mo ago
    The analogy in npm is dependency proliferation, along with what appears to be weaker community norms around security. To the extent that either or both of these are true, I think the “no way to prevent this” quip is essentially accurate.
• draw_down 5mo ago
  [dead]
• ch4s3 5mo ago
  NPM by virtue of its popularity and the vagaries of the ecosystem is always going to be a prime target for attackers, and people (maintainers) will always be a weak point.
  • freedomben 5mo ago
    I agree generally, but I also think it's important to point out that in the NPM ecosystem it is culturally acceptable and even encouraged to install even trivial dependencies to avoid reinventing the wheel. Philosophically I completely agree with this, though practically we see the result and it is not good. The left pad debacle should have been a huge wake up call, but not really much seems to have changed after that. As long as developers in the ecosystem are cavalier about installing huge chains of dependencies, NPM will be an attractive target for attackers. Even though we wish it were not so, cultural problems seem to be the hardest technical problems to solve.
    • shoeb00m 5mo ago
      Most of these attacks have nothing to do with installing trivial dependencies. It’s usually because the authors npm tokens got hacked; often due to github actions. The issue is that github actions has too many security gaps that are easy to miss.
      • freedomben 5mo ago
        Fair point, although when you have dependencies from dozens or hundreds of different publishers, the risk is much higher because it only takes one getting compromised. If instead you only had a handful of core things, there's less surface area
      • OhMeadhbh 5mo ago
        No. It is partially due to trivial dependencies. With so many dependencies it is very difficult to evaluate the security posture of all the teams that are inserting themselves into your code. When I publish commercial software for Unices that use shared object libraries, one of the things we do before publishing is review known vulnerabilities of our 10 dependencies. That is a tractable number. I get a senior engineer to spend time with an intern and step them through the evaluation criteria. If the team managing a particular library grows lax over time with respect to responding to vulnerabilities, we move away from using that library. And we can do these things because there are a tractable number of dependencies. But yes, also GitHub is not pure as the driven slush. I agree with you on that.
• mghackerlady 5mo ago
  Language exclusive package managers like this are nightmares for security, but npm simply does things so poorly I feel like they wanted something insecure.
  • fmbb 5mo ago
    What about language exclusivity makes a package manager a security nightmare?
    • a1o 5mo ago
      Now I have to wonder if someone is targeting Homebrew too, thanks
      • mghackerlady 5mo ago
        That isn't a language exclusive package manager. I mean things like npm and pip. It isn't necessarily that they're language exclusive, it's that they all tend to have features that aren't good security wise because they aid in developing in that language
• tialaramex 5mo ago
  The "No way to prevent this" analogies seem to me to work better for Memory Safety because, as with Gun Safety, the simple fact is that everybody knows how to solve the problem, but one group insists it's impossible. There is crowing from the "Actually copy-paste is better" people when this happens, but when it's their turn they just jam their fingers in their ears. The memory safety and gun safety problems are the actual problem. Shai-Hulud would ruin your day if it got into the Odin release you used to build your software, or it was copy-pasted into your "vendor everything" C++ project, the choice not to have automation doesn't mean you fixed the problem.
  • nonethewiser 5mo ago
    >The "No way to prevent this" analogies seem to me to work better for Memory Safety because, as with Gun Safety, the simple fact is that everybody knows how to solve the problem, but one group insists it's impossible. I'm not following. Whats the 2nd Amendment equivalent for memory safety? The amount of C/C++ in production or something?
    • toast0 5mo ago
      > A well regulated Memory Operation, being necessary to the security of a free Computer, the right of the people to keep and bear Pointer Arithmetic, shall not be infringed. (maybe workshop this)
  • cuuupid 5mo ago
    I'll disagree because the primary issues with gun control in the US are: [1] Guns are a core part of culture for much of America, very deeply so outside coastal cities. Most of the left wing in the US lives in coastal cities and either grew up there or immigrated very recently and does not leave, so this is an alien concept to them, but even in very blue cities like D.C. you would be shocked how many liberal democrats have armories. It is literally amendment #2! [2] They are already widely distributed and it would be a logistical impossibility to actually enforce gun control. This is directly analogous to NPM where: [1] The package registry working the way it does and people quickly installing packages without thinking much is deeply part of JS culture. It doesn't help that JS caters very heavily to as wide of a market as possible, of which the majority is going to be entry level/junior to associate engineers for whomst script kiddying or letting AI install whatever is essentially a way of life. As evidence, this type of thing is not really a problem with derivatives like Bun, especially in mature organizations where it's easy to enforce a minimum 72 hour wait time between publish and installation of a package. [2] Packages are already widely distributed and part of dependency stacks (e.g. the infamous leftpad) where it is a logistical impossibility to change how things work. I also view startups and companies like Vercel as essentially the NRA here, Next.js has taken over huge swathes of the ecosystem and highly encourages dependency-maxxing. Another direct analogy: proponents of gun control say they are unnecessary for self defense (esp. because law enforcement is good now), too heavy duty to begin with, and fundamentally dangerous. Similarly I would criticize dependency-maxxing as unnecessary for capability (esp. because AI is good now), too heavy duty to begin with, and fundamentally dangerous.
• b0rtb0rt 5mo ago
  after running the original version of this into the ground we can run this one into the ground too