10 ms·

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face. But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to do without. Well, now we're reaching the "find out" part of the process I guess.

amelius 5mo ago
lim (num_packages_in_system -> inf) p(successful_supply_chain_attack) = 1
tclancy 5mo ago
So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence service around the world? Just an idea I have been playing with. Say it basically cleans up everything and everyone looking for exploits has to start from scratch except “scratch” is now a place where any useful piece of software has been fuzz tested, property tested and formally verified. Assuming we survive the gap period where every country chucks what they still have at their worst enemies, I mean. I suppose we can always hit each other with animal bones.
- xingped 5mo ago
  TBH this is a pretty good way of looking at it. Yeah we're seeing an explosion of vulnerabilities being found right now, but that (hopefully) means those vulnerabilities are all being cleaned up and we're entering a more hardened era of software. Minus the software packages that are being intentionally put out as exploits, of course. Maybe some might say it's too optimistic and naive, but I think you have a good point.
  - anankaie 5mo ago
    To be fair, to some extent that’s up to us. Time to get cleaning, I guess.
  - FrinkleFrankle 5mo ago
    New code will also use these tools from the get go, hopefully vastly reducing the vulnerabilities that make it to prod to begin with.
    - gred 5mo ago
      The future may be distributed quite unevenly here, as they say, with a divergence between a small amount of "responsible" code in systems which leverage AI defensively, and a larger amount of vibe-coded / prompt-engineered code in systems which don't go through the extra trouble, and in fact create additional risk by cutting corners on human review. I personally know a lot of people using AI to create software faster, but none of them have created special security harnesses a la Mozilla (https://arstechnica.com/information-technology/2026/05/mozilla-says-271-vulnerabilities-found-by-mythos-have-almost-no-false-positives/ https://arstechnica.com/information-technology/2026/05/mozil...).
  - akoboldfrying 5mo ago
    > we're entering a more hardened era of software This is one force that operates. Another is that, in an effort to avoid depending on such a big attack surface, people are increasingly rolling their own code (with or without AI help) where they might previously have turned to an open source library. I think the effect will generally be an increase in vulnerabilities, since the hand-rolled code hasn't had the same amount of time soaking in the real world as the equivalent OS library; there's no reason to assume the average author would magically create fewer bugs than the original OS library authors initially did. But the vulnerabilities will have much narrower scope: If you successfully exploit an OS library, you can hack a large fraction of all the code that uses it, while if you successfully exploit FooCorp's hand-rolled implementation, you can only hack FooCorp. This changes the economic incentive of funding vulnerabilities to exploit -- though less now than in the past, when you couldn't just point an LLM at your target and tell it "plz hack".
    - cratermoon 5mo ago
      Typically when hand-rolling code you implement only what you require for your use-case, while a library will be more general purpose. As a consequence of doing more, have more code and more bugs. Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. For supply chain security and bug count, I'll take a focused custom implementation of specific features over a library full of generalized functionality.
      - akoboldfrying 5mo ago
        Yes, a lot hinges on how little you can get away with implementing for your use case. If you have an XML config file with 3 settings in it, you probably won't need to implement handling of external entities the way a full XML parsing library would, which will close off an entire class of attendant vulnerabilities. > Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. This isn't really an argument in favour of having the average programmer reimplement stuff, though. For it to be, you'd have to argue that the leftpad author was unusually sloppy. That may be true in this specific case, but in general, I'm not persuaded that the average OSS author is worse than the average programmer overall. IMHO, contributing your work to an OSS ecosystem is already a mild signal of competence. On the wider topic of reimplementation: Recently there was an article here about how the latest Ubuntu includes a bunch of coreutils binaries that have been rewritten in Rust. It turns out that, while this presumably reduced the number of memory corruption bugs (there was still one, somehow; I didn't dig into it), it introduced a bunch of new vulnerabilities, mostly caused by creating race conditions between checking a filesystem path and using the path for something.
  - michaelchisari 5mo ago
    I agree with the prediction but not the timing. We won't enter a more hardened era of software until after a long period of security vulnerabilities. Rivers caught on fire for a hundred years before the EPA was formed.
  - larodi 5mo ago
    You are avoiding intentionally to say ‘thanks to LLMs’ or is implicit? As all these recent mega bugs surface with lots of fuzzing and agentic bashing, right ?
    - jangxx 5mo ago
      Thank you for reminding us all that you AI bros are still the most obnoxious people there are.
      - larodi 5mo ago
        Indeed, yet another proof, there's the part of HN crowd which is passive aggressive, dismissive, and dishonest in the very scientific possible sense. Won't make my day harder than it is, but is a very weak signal. If I'm to be offended by a single thing in your post that is calling me (names) - is AI Bro. This was undeserved, and cannot be farther from the truth. Not to miss the fact your comment is entirely off topic, and perhaps you see AI bros everywhere now.
        12_throw_away 5mo ago
        This seems like a very emotional response, which is off-topic for HN. Consider using facts and logic to make calm, rational arguments.
        larodi 5mo ago
        What facts did parent use? What facts did u use? Which particular emotion do you imply in you response?
- marcus_holmes 5mo ago
  This assumes that there are no new exploits being generated. We're seeing maintainers retreat from maintaining because the amount of AI slop being pushed at them is too much. How many are just going to hand over the maintenance burden to someone else, and how many of those new maintainers are going to be evil? The essential problem is that our entire system of developing civilisation-critical software depends on the goodwill of a limited set of people to work for free and publish their work for everyone else to use. This was never sustainable, or even sensible, but because it was easy we based everything on it. We need to solve the underlying problem: how to sustainably develop and maintain the software we need. A large part of this is going to have to be: companies that use software to generate profits paying part of those profits towards the development and maintenance of that software. It just can't work any other way. How we do this is an open question that I have no answers for.
  - teiferer 5mo ago
    That is already how it works. The loner hacker in moms basement working for free on his super critical OSS package is largely a myth. The vast majority of OSS code is contributed by companies paying their employees to work on it.
    - larodi 5mo ago
      The sad truth about open source in 2026 is that it does not serve the society the way it is advertised or did back in the 90s.
      - spockz 5mo ago
        How so? We have open source operating systems running on a whole sleuth of systems ages apart. Interesting ideas and open collaboration coming out of the OS world. This opposed to closed off “products” that change at the whims of the company owning it.
        larodi 5mo ago
        Statistically. Most of it is created to serve marketing, personal or other agenda needs and is sponsored through the corresponding means for it. There’s a lot of misconception about how the open source comes to be and very small part, still significant of course, of it was really created for the benefit of a community. There are exceptions, but dig the organisational culture and origins and you’ll see the pattern. Also, thousands of projects are made for the satisfaction of the author himself being highly intelligent and high on algorithmic dopamine.
- Barbing 5mo ago
  Will need those animal bones if all the industrial control systems get turned against us Nuclear might be airgapped but what about water, power…?
- allthetime 5mo ago
  New software is being generated faster than it can be adequately tested. We are in the same place we’ve always been; except everything is moving much too fast.
  - repelsteeltje 5mo ago
    This is exactly the feeling I have. First: excessive growth of dependencies fueled by free components. * with internet access to FOSS via sourceforge and github we got an abundance of building blocks * with central repositories like CPAN, npm, pip, cargo and docker those building blocks became trivially easy to use Then LLMs and agents added velocity to building apps and producing yet more components, feeding back into the dependency chain. Worse: new code with unattributed reuse of questionable patterns found in unknowable versions of existing libraries. That is, implicit dependencies on fragments multitude of packages. This may all end well ultimately, but we're definitely in for a bumpy ride.
  - ClikeX 5mo ago
    I'm somehow reminded of Wile E Coyoto running off a ledge, staying afloat until he realizes there is no more ground under his feet.
- jpollock 5mo ago
  Faults are injected into the code at a constant rate per developer. Then there's the intentional injections. Auto-installing random software is the problem. It was a problem when our parents did it, why would it be a good idea for developers to do it?
  - teiferer 5mo ago
    curl ... | sudo bash yolo!
  - rounce 5mo ago
    This is related to a massive annoyance of mine: when I run a piece of software and the system is missing a required dependency, I want the software to *tell me* that dependency is missing so I can make a decision about proceeding or not. Instead it seems that far too often software authors will try and be “clever” by silently installing a bunch of dependencies, either in some directory path specific to the software, or even worse globally. I run a distro that often causes software like this to break because their silent automatic installation typically makes assumptions about Linux systems which don’t apply to mine. However I fear for the many users of most typical distros (and other OS’ in general as it’s not just a Linux-only issue) who are subject to having all sorts of stuff foisted onto their system with little to no opportunity to easily decide what is being heaped upon them.
    - skydhash 5mo ago
      Ruby gems and CPAN have build scripts that rebuild stuff on the user's device (and warn you if they can't find a dependency). But I believe one of the Python's tools that started the trend of downloading binaries instead of building them. Or was it NPM?
      - Izkata 5mo ago
        Python's pip predates npm, installs dependencies automatically, can include binaries, and the old-style packages could run arbitrary code during the install. Ruby gems are older than that, but I have no idea what capabilities it has/had.
- bulbar 5mo ago
  I think it will be an arms race in the future as well. Easier to fix known vulnerabilities automatically, but also easier to find new ones and the occasionally AI fuckup instead of the occasionally human fuckup.
  - bigiain 5mo ago
    Yeah. Right now it kinda feels to me like "Open Source" is the Russian army, assuming their sheer numbers and their huge quantity of equipment much off which is decades old. Meanwhile attackers and bug hunters are like the Ukrainians, using new, inexpensive, and surprisingly powerful tools that none of the Open Source community has ever seen in the past, and for which it has very little defence capability. The attackers with cheap drones or LLMs are completely overwhelming the old school who perhaps didn't notice how quickly the world has changed around them, or did notice but cannot do anything about quickly enough.
    - Brian_K_White 5mo ago
      Well this argument was certainly inventive. What a weird impression to have about these things. Who exactly is the innocent little Ukraine supposed to be that the big bad open source is supposed to be attacking to, what? take their land and make the OSS leader look powerful and successful at acheiving goals to distract from their fundamental awfulness? And who are the North Korean canon fodder purchased by OSS while we're at it? Yeah it's just like that, practically the same situation. The authors of gnu cp and ls can't wait to get, idk, something apparently, out of the war they started when they attacked, idk, someone apparently.
      - bigiain 5mo ago
        I guess I should have realised that comment could be so easily interpreted in ways I hadn't intended - given the political nature of that war. I wasn't intending to pass judgement on which side is the "innocent little" and which is the "big bad", but I (and the downvoters) clearly see the it obviously reads one specific way. I wish I'd chosen a less contentious example of a unarguably good army that's 50 or 100 years old and is still using tactics and equipment from the 70s and earlier, fighting against a somewhat less clearly "good" army using new tools that barely existed 5 years ago and new tactics that the older army (and everybody else) has never seem before with the capability to create new weapons and adjust tactics at speeds previously thought impossible. But that war doesn't exist (at least not outside of blindly loyal Russia supporters). For the record, I believe Russia is clearly on the side of evil and Ukraine is clearly on the side of good in this conflict.
- teiferer 5mo ago
  What we are seeing so far come out of the AI agent era is reduced not increased code quality. The few advances are by far negated by all the slop that's thrown around and that's unlikely to change. > any useful piece of software has been fuzz tested, property tested and formally verified. That would require effort. Human effort and extra token cost. Not going to happen, people want to rather move fast an break things.
  - Hfuffzehn 5mo ago
    Isn't blaming AI for that similar to blaming C for buffer overflows? More people are producing more code because of easier tools. Most code is bad. But that's not the tools fault. And in the end it is a problem of processes and culture.
    - teiferer 5mo ago
      We are not in disagreement here. I'm not blaming AI, I'm blaming the culture around its use.
  - tclancy 5mo ago
    >What we are seeing so far come out of the AI agent era is reduced not increased code quality. I am not disagreeing in the main, but I wonder about the net effect. Again, this is total speculation on my part. If I vibe-slop a half dozen apps this week (and I might, just you watch), the overall raw code quality in the universe got worse. But if in the space of the same time, two major security holes got patched (assume there was no net amount of code changed), didn't things actually get better?
- mahart 5mo ago
  Having casually read into a few recent incidents the vector has often been outside of software. A lot of mis-configurations or simply attacking the human in the chain. And nation states have basically unbounded resources for everything from bribes, insiders, and even standing up entire companies.
- dml2135 5mo ago
  Here's a crazy idea -- what if some of these vulnerabilities are surfacing because they have actually been found, already, and exist in the training data? Even an intelligence agency doesn't have perfect opsec, and something could get mentioned offhand somewhere on a forum, but never get picked up until the LLM uses it.
josephg 5mo ago
I've been wanting a capability based security model for years. Argued about it here in fact. Capabilities are kind of an object pointer with associated permissions - like a unix file descriptor. We should have: - OS level capabilities. Launched programs get passed a capability token from the shell (or wherever you launched the program from). All syscalls take a capability as the first argument. So, "open path /foo" becomes open(cap, "/foo"). The capability could correspond to a fake filesystem, real branch of your filesystem, network filesystem or really anything. The program doesn't get to know what kind of sandbox it lives inside. - Library / language capabilities. When I pull in some 3rd party library - like an npm module - that library should also be passed a capability too, either at import time or per callsite. It shouldn't have read/write access to all other bytes in my program's address space. It shouldn't have access to do anything on my computer as if it were me! The question is: "What is the blast radius of this code?" If the library you're using is malicious or vulnerable, we need to have sane defaults for how much damage can be caused. Calling lib::add(1, 2) shouldn't be able to result in a persistent compromise of my entire computer. SeL4 has fast, efficient OS level capabilities. Its had them for years. They work great. They're fast - faster than linux in many cases. And tremendously useful. They allow for transparent sandboxing, userland drivers, IPC, security improvements, and more. You can even run linux as a process in sel4. I want an OS that has all the features of my linux desktop, but works like SeL4. Unfortunately, I don't think any programming language has the kind of language level capabilities I want. Rust is really close. We need a way to restrict a 3rd party crate from calling any unsafe code (including from untrusted dependencies). We need to fix the long standing soundness bugs in rust. And we need a capability based standard library. No more global open() / listen() / etc. Only openat(), and equivalents for all other parts of the OS. If LLMs keep getting better, I'm going to get an LLM to build all this stuff in a few years if nobody else does it first. Security on modern desktop operating systems is a joke.
- theamk 5mo ago
  Note that capabilities would not help for those bugs we are discussing today. Those exploits are in kernel, and the userspace is only calling the normal, allowed calls. Removing global open()/listen()/etc.. with capability-based versions would still allow one to invoke the same kernel bugs. (Now, using microkernel like seL4 where the kernel drivers are isolated _would_ help, but (1) that's independent from what userspace does, you can have POSIX layer with seL4 and (2) that would be may more context switches, so a performance drop)
j45 5mo ago
Thinks might have to start considering server side technologies a bit more if at least being mindful of build processes.
- marcus_holmes 5mo ago
  It's not just client-side npm though. Rust has the same problem. Edit: and, ofc, what we're discussing here is Linux packages.
chasil 5mo ago
I am so happy to go through another round of kernel RPMs after the freak out today! I have one server that has shell users, and I did the "yum update" and "reboot -f" dance last week. Was that good enough? Oh no. Here we go again!
- baq 5mo ago
  Fortunately the issue isn’t fixed yet, so you don’t have to :)
organ1cwast3 5mo ago
[flagged]
- ryandrake 5mo ago
  Considering the amount of money at stake, Software is a deeply, deeply unserious and careless industry, and a great many practitioners are also deeply unserious and careless people. Yet, somehow the world goes on, these companies siphon up money, and all harms they cause are externalized.
  - organ1cwast3 5mo ago
    Well yeah; data breaches been a thing forever. Physical reality never opened a black hole in San Fran because someone committed a key to Github or a box of tapes destined for Iron Mountain vanished. A lot of the concerns are themselves social paranoias not real concerns. Which is where the unserious emerges but in a subtle way; taking such unserious things so seriously is not serious behavior. It's anxious and paranoid, aloof and clueless behavior. Secure in tech skills but unserious otherwise. Lacking a broad set of skills will make office workers unable to grow a potato inherently paranoid about their job.
  - inejge 5mo ago
    > Considering the amount of money at stake, Software is a deeply, deeply unserious and careless industry, and a great many practitioners are also deeply unserious and careless people. What else do you expect, given the economic incentives on one side, and the immaturity of the discipline on the other? Writing robust software requires time, money and competence, in a purely empirical approach, since we have no fundamental theory of software. The pressure is for quantity and features in minimum time. The approaches are incompatible, and economics win every time.
- homebrewer 5mo ago
  IT is (was?) one of the very few ways for us in third-world countries to pull ourselves out of poverty by our own bootstraps, since social mobility is quite limited if you lack the right connections. I'm pleased with you being so happy about it being taken away to make more money for billionaires.
bulbar 5mo ago
Realistically, most folks don't get paid to mitigate long term risks by deviation from the common (and more efficient) practice. Big companies have security roles on multiple levels, enforcing policies and not allowing devs to just install any package. That's not new but started maybe 15 years ago.
c7b 5mo ago
My pet theory is that package managers will one day be seen like we see object-oriented programming today. As something that was once popular but that we've since grown out of. It's also a design flaw that I see in cargo/Rust. Having to import 3rd party packages with who-knows-what dependencies to do pretty much anything, from using async to parsing JSON, it's supply chain vulnerability baked into the language philosophy. npm is no better, but I'm mentioning Rust specifically because it's an otherwise security-conscious language.
- weregiraffe 5mo ago
  But you can't expect the language std to supply you with every package under the sun.
  - c7b 5mo ago
    I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer. One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable packages, and a bigger standard library. Much harder to imagine a left-pad incident in such an ecosystem.
    - well_ackshually 5mo ago
      >C/C++ are doing fine without package managers. They're not either, every one of these projects contains a gigantic vendor/ folder full of unmaintained libraries, modified so much that keeping up with the latest changes is impossible so they're stuck with whatever version they copied back in 2009.
      - jkercher 5mo ago
        You make that sound worse than it is. On the overall topic, you have 0 supply chain risk, and the whole thing is local. Also, your code from 2009 is still valid. That would be a foreign concept in some languages like Python.
dguest 5mo ago
Most people will avoid sticking things in their mouth by default. They don't wait for the microbial cultures to come back positive to say no. We need a cultural shift toward code hygiene, which isn't really any different from the norms most cultures develop around food. It's a mix of crude heuristics but the sense of "eeew" is keeping billions of people alive.
- noduerme 5mo ago
  The billions of burgers served by fast food franchises with long histories of poisoning people would argue that delicious convenience overrides the hygiene instinct. Which is to say: Hiding the sausage-making is a core aspect of what makes supply chains profitable.
- oever 5mo ago
  That means going back to disabling Javascript or only allowing widely used, well-maintained Javascript libraries.
  - mschuster91 5mo ago
    > or only allowing widely used, well-maintained Javascript libraries. That isn't a guarantee either, just last month someone compromised the Axios library.
    - skydhash 5mo ago
      They stole the axios's npm keys and they uploaded malicious artifacts. They did not takeover the axios's repo. The issue is with packaging and distribution, not with code.
      - pocksuppet 5mo ago
        What's the meaningful distinction between those two things? You imported axios, you got pwned. Same result either way.
larodi 5mo ago
Indeed - one year ago we floated the idea it is better to write your code if you can, than get third parties. But it was a heresy at the time to consider LLMm filling the gaps. Today I’m limiting the exposure to dependencies more than ever, and particularly for things that take few hundred lines to implement. It’s a paradigm shift, no less.
- noduerme 5mo ago
  There are a lot of libs you really can't justify implementing from scratch. Mathjs and node-mysql jump to mind. Poisoned chains build up from small dependencies, and clearly staying on top of your dependency chain should be a full time job - if anyone was willing to pay someone to do that full time.
  - larodi 5mo ago
    Of course, and thank God for them. But many more look more complicated and serve more use case than you typically actually need. Like - how much of ffmpeg you need, well depends on the project. And perhaps someone is happily tearing it down with LLM to get precisely these parts (not me, though I enjoy doing it to LLMs and other models). But being able to have agents implement pelr5 in rust and make it faster and more secure raises many questions towards the role of open source and consequences of security and supply chain risks.
- orbital-decay 5mo ago
  This replaces supply chain trust with the trust in the LLM and the provider you're using. Even if you exclude model devs from your threat model and are running the LLM yourself, it's still an uninterpretable black box that is trained on the web data which can be and is manipulated precisely to attack LLMs during training. So this approach still needs proper supply chain security.
  - larodi 5mo ago
    Well it needs, and in particular if you use an adversarial model tuned to inject malware. Not sure if it was researched though to this degree and no provider would tell you anyways I guess :)
YZF 5mo ago
I worked for one company where we were super conservative. Every external component was versioned. Nothing was updated without review and usually after it had plenty of soak time. Pretty much everything built from source code (compilers, kernel etc.). Builds [build servers/infra] can't reach the Internet at all and there's process around getting any change in. We reviewed all relevant CVEs as they came out to make a call on if they apply to us or not and how we mitigate or address them. Then I moved to another company where we had builds that access the Internet. We upgrade things as soon as they come out. And people think this is good practice because we're getting the latest bug fixes. CVEs are reviewed by a security team. Then a startup with a mix of other practices. Some very good. But we also had a big CVE debt. e.g. we had secure boots on our servers and encrypted drives. We had a pretty good grasp on securing components talking to each other etc. Everyone seems to think they are doing the right thing. It's impossible to convince the "frequent upgrader" that maybe that's a risk in terms of introducing new issues. We as an industry could really use a better set of practices. Example #1 for me is better in terms of dependency management. In general company #1 had well established security practices and we had really secure products.
- dataflow 5mo ago
  > Everyone seems to think they are doing the right thing I like to think people would agree more on the appropriate method if they saw the risk as large enough. If you could convince everyone that a nuclear bomb would get dropped on their heads (or a comparably devastating event) if a vulnerability gets in, I highly doubt a company like #2 would still believe they're doing things optimally, for example.
  - emodendroket 5mo ago
    Really? You think the alternate mode where you're running 5-year-old versions of stuff with tons of known security flaws is better?
    - coldtea 5mo ago
      What part of "We reviewed all relevant CVEs as they came out to make a call on if they apply to us or not and how we mitigate or address them" gave you that impression?
rerdavies 5mo ago
I am feeling really uncomfortable sitting on a large React project. Whether to do constant npm upgrades to keep the high-priority security issues count at zero (for what seems like about 15 minutes), or whether to hang back a bit to avoid catching the big one that everyone knows is coming real soon now. Not enjoying npm at all.
emodendroket 5mo ago
Right, yeah, instead you can run ancient versions of everything and encounter a whole different class of risks
- cenamus 5mo ago
  That's not at all what OP is talking about.
sergeykish 5mo ago
Web pages handled by browsers. Linux desktop running code without sandbox is reckless, relied on verification by distro maintainers, does not work the moment users run proprietary software. Programming language packages issue only because we don't have zero trust for modules — no restrictions to open socket or file system. Issue is not count, pure function leftPad can't hurt you.
JulienBrouchier 5mo ago
There are positive things happening too. Recently, npm released min-release-age filtering the lets you only import packages that have a certain vintage, protecting you from all these supply chain attacks as they tend to be quickly detected. https://github.com/npm/cli/releases/tag/v11.10.0 https://github.com/npm/cli/releases/tag/v11.10.0
anthk 5mo ago
This never happened under CPAN/CTAN. This wasn't a nightmare wanting to happen, but an example of badly maintaned systems for the lowest common denominator.
Joeri 5mo ago
Blaming the victim is too easy. NPM is unsafe at any speed. You cannot use it in any but the most trivial capacities without opening yourself up to supply chain attacks. Why is npm the only package ecosystem that has so many problems? What are the other package system owners doing better? Let’s start there, instead of blaming the victims.
- marcus_holmes 5mo ago
  This is talking about Linux packages. So no, not just npm.
Animats 5mo ago
> The sheer mass of packages Yes. I just noticed that a Rust program I'm working on had acquired a plotter driver crate. A plotter driver? The program has no graphical output. Turns out that "kdtree" has a dev dependency on a profiling library that pulls in a whole graphics system. Even in release mode, I get that, because I have debug symbols turned on, which activated dev dependencies. Aargh.
- endospore 5mo ago
  > I have debug symbols turned on, which activated dev dependencies Nope that doesn't happen. It's not compiled into your binary if it's a dev or build dependency. Cargo may have downloaded the crate source according to the lockfile and that's it, it shouldn't build anything unneeded.
  - Animats 5mo ago
    OK, I have to check the binary.

amelius 5mo ago

lim (num_packages_in_system -> inf) p(successful_supply_chain_attack) = 1

tclancy 5mo ago

So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence service around the world? Just an idea I have been playing with. Say it basically cleans up everything and everyone looking for exploits has to start from scratch except “scratch” is now a place where any useful piece of software has been fuzz tested, property tested and formally verified. Assuming we survive the gap period where every country chucks what they still have at their worst enemies, I mean. I suppose we can always hit each other with animal bones.

xingped 5mo ago
TBH this is a pretty good way of looking at it. Yeah we're seeing an explosion of vulnerabilities being found right now, but that (hopefully) means those vulnerabilities are all being cleaned up and we're entering a more hardened era of software. Minus the software packages that are being intentionally put out as exploits, of course. Maybe some might say it's too optimistic and naive, but I think you have a good point.
- anankaie 5mo ago
  To be fair, to some extent that’s up to us. Time to get cleaning, I guess.
- FrinkleFrankle 5mo ago
  New code will also use these tools from the get go, hopefully vastly reducing the vulnerabilities that make it to prod to begin with.
  - gred 5mo ago
    The future may be distributed quite unevenly here, as they say, with a divergence between a small amount of "responsible" code in systems which leverage AI defensively, and a larger amount of vibe-coded / prompt-engineered code in systems which don't go through the extra trouble, and in fact create additional risk by cutting corners on human review. I personally know a lot of people using AI to create software faster, but none of them have created special security harnesses a la Mozilla (https://arstechnica.com/information-technology/2026/05/mozilla-says-271-vulnerabilities-found-by-mythos-have-almost-no-false-positives/ https://arstechnica.com/information-technology/2026/05/mozil...).
- akoboldfrying 5mo ago
  > we're entering a more hardened era of software This is one force that operates. Another is that, in an effort to avoid depending on such a big attack surface, people are increasingly rolling their own code (with or without AI help) where they might previously have turned to an open source library. I think the effect will generally be an increase in vulnerabilities, since the hand-rolled code hasn't had the same amount of time soaking in the real world as the equivalent OS library; there's no reason to assume the average author would magically create fewer bugs than the original OS library authors initially did. But the vulnerabilities will have much narrower scope: If you successfully exploit an OS library, you can hack a large fraction of all the code that uses it, while if you successfully exploit FooCorp's hand-rolled implementation, you can only hack FooCorp. This changes the economic incentive of funding vulnerabilities to exploit -- though less now than in the past, when you couldn't just point an LLM at your target and tell it "plz hack".
  - cratermoon 5mo ago
    Typically when hand-rolling code you implement only what you require for your use-case, while a library will be more general purpose. As a consequence of doing more, have more code and more bugs. Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. For supply chain security and bug count, I'll take a focused custom implementation of specific features over a library full of generalized functionality.
    - akoboldfrying 5mo ago
      Yes, a lot hinges on how little you can get away with implementing for your use case. If you have an XML config file with 3 settings in it, you probably won't need to implement handling of external entities the way a full XML parsing library would, which will close off an entire class of attendant vulnerabilities. > Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. This isn't really an argument in favour of having the average programmer reimplement stuff, though. For it to be, you'd have to argue that the leftpad author was unusually sloppy. That may be true in this specific case, but in general, I'm not persuaded that the average OSS author is worse than the average programmer overall. IMHO, contributing your work to an OSS ecosystem is already a mild signal of competence. On the wider topic of reimplementation: Recently there was an article here about how the latest Ubuntu includes a bunch of coreutils binaries that have been rewritten in Rust. It turns out that, while this presumably reduced the number of memory corruption bugs (there was still one, somehow; I didn't dig into it), it introduced a bunch of new vulnerabilities, mostly caused by creating race conditions between checking a filesystem path and using the path for something.
- michaelchisari 5mo ago
  I agree with the prediction but not the timing. We won't enter a more hardened era of software until after a long period of security vulnerabilities. Rivers caught on fire for a hundred years before the EPA was formed.
- larodi 5mo ago
  You are avoiding intentionally to say ‘thanks to LLMs’ or is implicit? As all these recent mega bugs surface with lots of fuzzing and agentic bashing, right ?
  - jangxx 5mo ago
    Thank you for reminding us all that you AI bros are still the most obnoxious people there are.
    - larodi 5mo ago
      Indeed, yet another proof, there's the part of HN crowd which is passive aggressive, dismissive, and dishonest in the very scientific possible sense. Won't make my day harder than it is, but is a very weak signal. If I'm to be offended by a single thing in your post that is calling me (names) - is AI Bro. This was undeserved, and cannot be farther from the truth. Not to miss the fact your comment is entirely off topic, and perhaps you see AI bros everywhere now.
      - 12_throw_away 5mo ago
        This seems like a very emotional response, which is off-topic for HN. Consider using facts and logic to make calm, rational arguments.
        larodi 5mo ago
        What facts did parent use? What facts did u use? Which particular emotion do you imply in you response?
marcus_holmes 5mo ago
This assumes that there are no new exploits being generated. We're seeing maintainers retreat from maintaining because the amount of AI slop being pushed at them is too much. How many are just going to hand over the maintenance burden to someone else, and how many of those new maintainers are going to be evil? The essential problem is that our entire system of developing civilisation-critical software depends on the goodwill of a limited set of people to work for free and publish their work for everyone else to use. This was never sustainable, or even sensible, but because it was easy we based everything on it. We need to solve the underlying problem: how to sustainably develop and maintain the software we need. A large part of this is going to have to be: companies that use software to generate profits paying part of those profits towards the development and maintenance of that software. It just can't work any other way. How we do this is an open question that I have no answers for.
- teiferer 5mo ago
  That is already how it works. The loner hacker in moms basement working for free on his super critical OSS package is largely a myth. The vast majority of OSS code is contributed by companies paying their employees to work on it.
  - larodi 5mo ago
    The sad truth about open source in 2026 is that it does not serve the society the way it is advertised or did back in the 90s.
    - spockz 5mo ago
      How so? We have open source operating systems running on a whole sleuth of systems ages apart. Interesting ideas and open collaboration coming out of the OS world. This opposed to closed off “products” that change at the whims of the company owning it.
      - larodi 5mo ago
        Statistically. Most of it is created to serve marketing, personal or other agenda needs and is sponsored through the corresponding means for it. There’s a lot of misconception about how the open source comes to be and very small part, still significant of course, of it was really created for the benefit of a community. There are exceptions, but dig the organisational culture and origins and you’ll see the pattern. Also, thousands of projects are made for the satisfaction of the author himself being highly intelligent and high on algorithmic dopamine.
Barbing 5mo ago
Will need those animal bones if all the industrial control systems get turned against us Nuclear might be airgapped but what about water, power…?
allthetime 5mo ago
New software is being generated faster than it can be adequately tested. We are in the same place we’ve always been; except everything is moving much too fast.
- repelsteeltje 5mo ago
  This is exactly the feeling I have. First: excessive growth of dependencies fueled by free components. * with internet access to FOSS via sourceforge and github we got an abundance of building blocks * with central repositories like CPAN, npm, pip, cargo and docker those building blocks became trivially easy to use Then LLMs and agents added velocity to building apps and producing yet more components, feeding back into the dependency chain. Worse: new code with unattributed reuse of questionable patterns found in unknowable versions of existing libraries. That is, implicit dependencies on fragments multitude of packages. This may all end well ultimately, but we're definitely in for a bumpy ride.
- ClikeX 5mo ago
  I'm somehow reminded of Wile E Coyoto running off a ledge, staying afloat until he realizes there is no more ground under his feet.
jpollock 5mo ago
Faults are injected into the code at a constant rate per developer. Then there's the intentional injections. Auto-installing random software is the problem. It was a problem when our parents did it, why would it be a good idea for developers to do it?
- teiferer 5mo ago
  curl ... | sudo bash yolo!
- rounce 5mo ago
  This is related to a massive annoyance of mine: when I run a piece of software and the system is missing a required dependency, I want the software to *tell me* that dependency is missing so I can make a decision about proceeding or not. Instead it seems that far too often software authors will try and be “clever” by silently installing a bunch of dependencies, either in some directory path specific to the software, or even worse globally. I run a distro that often causes software like this to break because their silent automatic installation typically makes assumptions about Linux systems which don’t apply to mine. However I fear for the many users of most typical distros (and other OS’ in general as it’s not just a Linux-only issue) who are subject to having all sorts of stuff foisted onto their system with little to no opportunity to easily decide what is being heaped upon them.
  - skydhash 5mo ago
    Ruby gems and CPAN have build scripts that rebuild stuff on the user's device (and warn you if they can't find a dependency). But I believe one of the Python's tools that started the trend of downloading binaries instead of building them. Or was it NPM?
    - Izkata 5mo ago
      Python's pip predates npm, installs dependencies automatically, can include binaries, and the old-style packages could run arbitrary code during the install. Ruby gems are older than that, but I have no idea what capabilities it has/had.
bulbar 5mo ago
I think it will be an arms race in the future as well. Easier to fix known vulnerabilities automatically, but also easier to find new ones and the occasionally AI fuckup instead of the occasionally human fuckup.
- bigiain 5mo ago
  Yeah. Right now it kinda feels to me like "Open Source" is the Russian army, assuming their sheer numbers and their huge quantity of equipment much off which is decades old. Meanwhile attackers and bug hunters are like the Ukrainians, using new, inexpensive, and surprisingly powerful tools that none of the Open Source community has ever seen in the past, and for which it has very little defence capability. The attackers with cheap drones or LLMs are completely overwhelming the old school who perhaps didn't notice how quickly the world has changed around them, or did notice but cannot do anything about quickly enough.
  - Brian_K_White 5mo ago
    Well this argument was certainly inventive. What a weird impression to have about these things. Who exactly is the innocent little Ukraine supposed to be that the big bad open source is supposed to be attacking to, what? take their land and make the OSS leader look powerful and successful at acheiving goals to distract from their fundamental awfulness? And who are the North Korean canon fodder purchased by OSS while we're at it? Yeah it's just like that, practically the same situation. The authors of gnu cp and ls can't wait to get, idk, something apparently, out of the war they started when they attacked, idk, someone apparently.
    - bigiain 5mo ago
      I guess I should have realised that comment could be so easily interpreted in ways I hadn't intended - given the political nature of that war. I wasn't intending to pass judgement on which side is the "innocent little" and which is the "big bad", but I (and the downvoters) clearly see the it obviously reads one specific way. I wish I'd chosen a less contentious example of a unarguably good army that's 50 or 100 years old and is still using tactics and equipment from the 70s and earlier, fighting against a somewhat less clearly "good" army using new tools that barely existed 5 years ago and new tactics that the older army (and everybody else) has never seem before with the capability to create new weapons and adjust tactics at speeds previously thought impossible. But that war doesn't exist (at least not outside of blindly loyal Russia supporters). For the record, I believe Russia is clearly on the side of evil and Ukraine is clearly on the side of good in this conflict.
teiferer 5mo ago
What we are seeing so far come out of the AI agent era is reduced not increased code quality. The few advances are by far negated by all the slop that's thrown around and that's unlikely to change. > any useful piece of software has been fuzz tested, property tested and formally verified. That would require effort. Human effort and extra token cost. Not going to happen, people want to rather move fast an break things.
- Hfuffzehn 5mo ago
  Isn't blaming AI for that similar to blaming C for buffer overflows? More people are producing more code because of easier tools. Most code is bad. But that's not the tools fault. And in the end it is a problem of processes and culture.
  - teiferer 5mo ago
    We are not in disagreement here. I'm not blaming AI, I'm blaming the culture around its use.
- tclancy 5mo ago
  >What we are seeing so far come out of the AI agent era is reduced not increased code quality. I am not disagreeing in the main, but I wonder about the net effect. Again, this is total speculation on my part. If I vibe-slop a half dozen apps this week (and I might, just you watch), the overall raw code quality in the universe got worse. But if in the space of the same time, two major security holes got patched (assume there was no net amount of code changed), didn't things actually get better?
mahart 5mo ago
Having casually read into a few recent incidents the vector has often been outside of software. A lot of mis-configurations or simply attacking the human in the chain. And nation states have basically unbounded resources for everything from bribes, insiders, and even standing up entire companies.
dml2135 5mo ago
Here's a crazy idea -- what if some of these vulnerabilities are surfacing because they have actually been found, already, and exist in the training data? Even an intelligence agency doesn't have perfect opsec, and something could get mentioned offhand somewhere on a forum, but never get picked up until the LLM uses it.

josephg 5mo ago

I've been wanting a capability based security model for years. Argued about it here in fact. Capabilities are kind of an object pointer with associated permissions - like a unix file descriptor. We should have: - OS level capabilities. Launched programs get passed a capability token from the shell (or wherever you launched the program from). All syscalls take a capability as the first argument. So, "open path /foo" becomes open(cap, "/foo"). The capability could correspond to a fake filesystem, real branch of your filesystem, network filesystem or really anything. The program doesn't get to know what kind of sandbox it lives inside. - Library / language capabilities. When I pull in some 3rd party library - like an npm module - that library should also be passed a capability too, either at import time or per callsite. It shouldn't have read/write access to all other bytes in my program's address space. It shouldn't have access to do anything on my computer as if it were me! The question is: "What is the blast radius of this code?" If the library you're using is malicious or vulnerable, we need to have sane defaults for how much damage can be caused. Calling lib::add(1, 2) shouldn't be able to result in a persistent compromise of my entire computer. SeL4 has fast, efficient OS level capabilities. Its had them for years. They work great. They're fast - faster than linux in many cases. And tremendously useful. They allow for transparent sandboxing, userland drivers, IPC, security improvements, and more. You can even run linux as a process in sel4. I want an OS that has all the features of my linux desktop, but works like SeL4. Unfortunately, I don't think any programming language has the kind of language level capabilities I want. Rust is really close. We need a way to restrict a 3rd party crate from calling any unsafe code (including from untrusted dependencies). We need to fix the long standing soundness bugs in rust. And we need a capability based standard library. No more global open() / listen() / etc. Only openat(), and equivalents for all other parts of the OS. If LLMs keep getting better, I'm going to get an LLM to build all this stuff in a few years if nobody else does it first. Security on modern desktop operating systems is a joke.

theamk 5mo ago
Note that capabilities would not help for those bugs we are discussing today. Those exploits are in kernel, and the userspace is only calling the normal, allowed calls. Removing global open()/listen()/etc.. with capability-based versions would still allow one to invoke the same kernel bugs. (Now, using microkernel like seL4 where the kernel drivers are isolated _would_ help, but (1) that's independent from what userspace does, you can have POSIX layer with seL4 and (2) that would be may more context switches, so a performance drop)

j45 5mo ago

Thinks might have to start considering server side technologies a bit more if at least being mindful of build processes.

marcus_holmes 5mo ago
It's not just client-side npm though. Rust has the same problem. Edit: and, ofc, what we're discussing here is Linux packages.

chasil 5mo ago

I am so happy to go through another round of kernel RPMs after the freak out today! I have one server that has shell users, and I did the "yum update" and "reboot -f" dance last week. Was that good enough? Oh no. Here we go again!

baq 5mo ago
Fortunately the issue isn’t fixed yet, so you don’t have to :)

organ1cwast3 5mo ago

[flagged]

ryandrake 5mo ago
Considering the amount of money at stake, Software is a deeply, deeply unserious and careless industry, and a great many practitioners are also deeply unserious and careless people. Yet, somehow the world goes on, these companies siphon up money, and all harms they cause are externalized.
- organ1cwast3 5mo ago
  Well yeah; data breaches been a thing forever. Physical reality never opened a black hole in San Fran because someone committed a key to Github or a box of tapes destined for Iron Mountain vanished. A lot of the concerns are themselves social paranoias not real concerns. Which is where the unserious emerges but in a subtle way; taking such unserious things so seriously is not serious behavior. It's anxious and paranoid, aloof and clueless behavior. Secure in tech skills but unserious otherwise. Lacking a broad set of skills will make office workers unable to grow a potato inherently paranoid about their job.
- inejge 5mo ago
  > Considering the amount of money at stake, Software is a deeply, deeply unserious and careless industry, and a great many practitioners are also deeply unserious and careless people. What else do you expect, given the economic incentives on one side, and the immaturity of the discipline on the other? Writing robust software requires time, money and competence, in a purely empirical approach, since we have no fundamental theory of software. The pressure is for quantity and features in minimum time. The approaches are incompatible, and economics win every time.
homebrewer 5mo ago
IT is (was?) one of the very few ways for us in third-world countries to pull ourselves out of poverty by our own bootstraps, since social mobility is quite limited if you lack the right connections. I'm pleased with you being so happy about it being taken away to make more money for billionaires.

bulbar 5mo ago

Realistically, most folks don't get paid to mitigate long term risks by deviation from the common (and more efficient) practice. Big companies have security roles on multiple levels, enforcing policies and not allowing devs to just install any package. That's not new but started maybe 15 years ago.

c7b 5mo ago

My pet theory is that package managers will one day be seen like we see object-oriented programming today. As something that was once popular but that we've since grown out of. It's also a design flaw that I see in cargo/Rust. Having to import 3rd party packages with who-knows-what dependencies to do pretty much anything, from using async to parsing JSON, it's supply chain vulnerability baked into the language philosophy. npm is no better, but I'm mentioning Rust specifically because it's an otherwise security-conscious language.

weregiraffe 5mo ago
But you can't expect the language std to supply you with every package under the sun.
- c7b 5mo ago
  I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer. One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable packages, and a bigger standard library. Much harder to imagine a left-pad incident in such an ecosystem.
  - well_ackshually 5mo ago
    >C/C++ are doing fine without package managers. They're not either, every one of these projects contains a gigantic vendor/ folder full of unmaintained libraries, modified so much that keeping up with the latest changes is impossible so they're stuck with whatever version they copied back in 2009.
    - jkercher 5mo ago
      You make that sound worse than it is. On the overall topic, you have 0 supply chain risk, and the whole thing is local. Also, your code from 2009 is still valid. That would be a foreign concept in some languages like Python.

dguest 5mo ago

Most people will avoid sticking things in their mouth by default. They don't wait for the microbial cultures to come back positive to say no. We need a cultural shift toward code hygiene, which isn't really any different from the norms most cultures develop around food. It's a mix of crude heuristics but the sense of "eeew" is keeping billions of people alive.

noduerme 5mo ago
The billions of burgers served by fast food franchises with long histories of poisoning people would argue that delicious convenience overrides the hygiene instinct. Which is to say: Hiding the sausage-making is a core aspect of what makes supply chains profitable.
oever 5mo ago
That means going back to disabling Javascript or only allowing widely used, well-maintained Javascript libraries.
- mschuster91 5mo ago
  > or only allowing widely used, well-maintained Javascript libraries. That isn't a guarantee either, just last month someone compromised the Axios library.
  - skydhash 5mo ago
    They stole the axios's npm keys and they uploaded malicious artifacts. They did not takeover the axios's repo. The issue is with packaging and distribution, not with code.
    - pocksuppet 5mo ago
      What's the meaningful distinction between those two things? You imported axios, you got pwned. Same result either way.

larodi 5mo ago

Indeed - one year ago we floated the idea it is better to write your code if you can, than get third parties. But it was a heresy at the time to consider LLMm filling the gaps. Today I’m limiting the exposure to dependencies more than ever, and particularly for things that take few hundred lines to implement. It’s a paradigm shift, no less.

noduerme 5mo ago
There are a lot of libs you really can't justify implementing from scratch. Mathjs and node-mysql jump to mind. Poisoned chains build up from small dependencies, and clearly staying on top of your dependency chain should be a full time job - if anyone was willing to pay someone to do that full time.
- larodi 5mo ago
  Of course, and thank God for them. But many more look more complicated and serve more use case than you typically actually need. Like - how much of ffmpeg you need, well depends on the project. And perhaps someone is happily tearing it down with LLM to get precisely these parts (not me, though I enjoy doing it to LLMs and other models). But being able to have agents implement pelr5 in rust and make it faster and more secure raises many questions towards the role of open source and consequences of security and supply chain risks.
orbital-decay 5mo ago
This replaces supply chain trust with the trust in the LLM and the provider you're using. Even if you exclude model devs from your threat model and are running the LLM yourself, it's still an uninterpretable black box that is trained on the web data which can be and is manipulated precisely to attack LLMs during training. So this approach still needs proper supply chain security.
- larodi 5mo ago
  Well it needs, and in particular if you use an adversarial model tuned to inject malware. Not sure if it was researched though to this degree and no provider would tell you anyways I guess :)

YZF 5mo ago

I worked for one company where we were super conservative. Every external component was versioned. Nothing was updated without review and usually after it had plenty of soak time. Pretty much everything built from source code (compilers, kernel etc.). Builds [build servers/infra] can't reach the Internet at all and there's process around getting any change in. We reviewed all relevant CVEs as they came out to make a call on if they apply to us or not and how we mitigate or address them. Then I moved to another company where we had builds that access the Internet. We upgrade things as soon as they come out. And people think this is good practice because we're getting the latest bug fixes. CVEs are reviewed by a security team. Then a startup with a mix of other practices. Some very good. But we also had a big CVE debt. e.g. we had secure boots on our servers and encrypted drives. We had a pretty good grasp on securing components talking to each other etc. Everyone seems to think they are doing the right thing. It's impossible to convince the "frequent upgrader" that maybe that's a risk in terms of introducing new issues. We as an industry could really use a better set of practices. Example #1 for me is better in terms of dependency management. In general company #1 had well established security practices and we had really secure products.

dataflow 5mo ago
> Everyone seems to think they are doing the right thing I like to think people would agree more on the appropriate method if they saw the risk as large enough. If you could convince everyone that a nuclear bomb would get dropped on their heads (or a comparably devastating event) if a vulnerability gets in, I highly doubt a company like #2 would still believe they're doing things optimally, for example.
- emodendroket 5mo ago
  Really? You think the alternate mode where you're running 5-year-old versions of stuff with tons of known security flaws is better?
  - coldtea 5mo ago
    What part of "We reviewed all relevant CVEs as they came out to make a call on if they apply to us or not and how we mitigate or address them" gave you that impression?

rerdavies 5mo ago

I am feeling really uncomfortable sitting on a large React project. Whether to do constant npm upgrades to keep the high-priority security issues count at zero (for what seems like about 15 minutes), or whether to hang back a bit to avoid catching the big one that everyone knows is coming real soon now. Not enjoying npm at all.

emodendroket 5mo ago

Right, yeah, instead you can run ancient versions of everything and encounter a whole different class of risks

cenamus 5mo ago
That's not at all what OP is talking about.

sergeykish 5mo ago

Web pages handled by browsers. Linux desktop running code without sandbox is reckless, relied on verification by distro maintainers, does not work the moment users run proprietary software. Programming language packages issue only because we don't have zero trust for modules — no restrictions to open socket or file system. Issue is not count, pure function leftPad can't hurt you.

JulienBrouchier 5mo ago

There are positive things happening too. Recently, npm released min-release-age filtering the lets you only import packages that have a certain vintage, protecting you from all these supply chain attacks as they tend to be quickly detected. https://github.com/npm/cli/releases/tag/v11.10.0 https://github.com/npm/cli/releases/tag/v11.10.0

anthk 5mo ago

This never happened under CPAN/CTAN. This wasn't a nightmare wanting to happen, but an example of badly maintaned systems for the lowest common denominator.

Joeri 5mo ago

Blaming the victim is too easy. NPM is unsafe at any speed. You cannot use it in any but the most trivial capacities without opening yourself up to supply chain attacks. Why is npm the only package ecosystem that has so many problems? What are the other package system owners doing better? Let’s start there, instead of blaming the victims.

marcus_holmes 5mo ago
This is talking about Linux packages. So no, not just npm.

Animats 5mo ago

> The sheer mass of packages Yes. I just noticed that a Rust program I'm working on had acquired a plotter driver crate. A plotter driver? The program has no graphical output. Turns out that "kdtree" has a dev dependency on a profiling library that pulls in a whole graphics system. Even in release mode, I get that, because I have debug symbols turned on, which activated dev dependencies. Aargh.

endospore 5mo ago
> I have debug symbols turned on, which activated dev dependencies Nope that doesn't happen. It's not compiled into your binary if it's a dev or build dependency. Cargo may have downloaded the crate source according to the lockfile and that's it, it shouldn't build anything unneeded.
- Animats 5mo ago
  OK, I have to check the binary.