Sick of "many dependencies" framing [LWN.net]

Sick of "many dependencies" framing

Posted Feb 11, 2026 7:17 UTC (Wed) by taladar (subscriber, #68407)
Parent article: FOSS in times of war, scarcity, and AI

> if FOSS has such a large attack surface in the form of so many libraries and dependencies

I am so sick of the dependency problem always being framed in terms of the number of dependencies rather than the amount of code involved and how well maintained, documented, tested,... it is.

Having one million lines of code in your dependencies does not get any better if it is in two dependencies of 500k lines each, 495k of which are essentially never looked at, nobody knows how they work and no tests exist for them but nominally they are "maintained" because they are part of another project that has some other lines that are properly maintained.

All having few large over many small dependencies achieves is that you have less information about the actual state of the code you depend on.

Sure, you have to deal with fewer organizations that handle that code if you have a small number of dependencies but that only really matters if you are more concerned with the bureaucracy of pretending everything is in a great state than with the actual state of the code.

to post comments

Sick of "many dependencies" framing

Posted Feb 11, 2026 7:29 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (6 responses)

Not really - the more maintainers I need to trust, the higher the probability that one of them is either malicious or is compromised in some way. Personally I think this is a reasonable tradeoff, but there's still some degree of additional attack surface as a result.

Sick of "many dependencies" framing

Posted Feb 11, 2026 10:43 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

The challenge is that maintainer count and dependency count are not correlated; large dependencies often have many maintainers, while it's possible for one person to maintain many small dependencies to a high standard.

Using dependency count as a proxy for something you really care about (like "how many maintainers am I trusting") increases the risk that you will consider yourself "safe" (because you're trusting a small number of dependencies) while actually being at risk (because one of those dependencies has a large number of trusted maintainers, and in the worst case, has a large number of transitively trusted maintainers hidden behind a small number of known maintainers - where you can't actually see directly that someone maintaining the printer support in GTK4 is not on the list of people you've identified as the "GTK Development Team").

Dependency count works within a single build ecosystem as a proxy, because everyone using (say) Bazel, or Cargo, or CMake, faces the same challenges integrating one more dependency - so a CMake project with 15 dependencies probably trusts more people than a CMake project with 10 dependencies. But once you start comparing across build ecosystems, you run into the issue that some ecosystems have a single maintainer comfortably maintaining 15 dependencies in usable form (split up so that you only pull in code you care about), while other ecosystems push maintainers to group together, so that each dependency represents multiple trusted maintainers.

Sick of "many dependencies" framing

Posted Feb 11, 2026 11:42 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (2 responses)

Dependency counts work because they reduce the relationship graph to something a human can understand and act on.

Software is a human creation where human relationships matter, infinite delegation chains do not work for humans and are ripe for abuse, that’s why no one is surprised when a non-software project goes overboard and the inquest shows deep levels of subcontracting, that’s why the automotive industry co-locates its suppliers as close to its own factories as possible (sometimes the next side of the road with a bridge over the road to reduce the effective distance further).

Delegation abuse breads lack of accountability. Software may be special but the humans writing software are not.

Sick of "many dependencies" framing

Posted Feb 11, 2026 12:17 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

Dependency counts reduce the relationship graph by hiding significant portions of it behind invisible delegation chains, with the very problems you cite with deep levels of subcontracting.

In the extreme case, you replace 200 visible maintainers (maintaining 500 visible dependencies - one person maintaining several related dependencies, but splitting them up for your benefit in choosing which bits of their code you use), with 5 visible maintainers maintaining 5 visible dependencies, and a total trust set on the order of 20,000 people, of whom only 200 are actively working on the parts of your dependencies that you use (but where any of them could introduce malicious code and break your trust in that dependency).

And that's why I consider dependency count a bad metric - by saying "I want a small dependency count, with a small number of top-level maintainers", you don't reduce the amount of code you depend upon, but you do incentivise those top-level maintainers to abuse delegation so that they can offer you a single large dependency that does everything you want, rather than offering 10 smaller dependencies, of which 2 are helpful, and requiring you to pick up the other 90 functions they could put in their dependency via delegation abuse from other places.

Sick of "many dependencies" framing

Posted Feb 11, 2026 13:18 UTC (Wed) by Wol (subscriber, #4433) [Link]

And this is also an argument against dynamic linking. If I dynamic-link a library, ALL that code is available to an attacker, and needs to be vetted.

Okay, it's not true of all static linking, but the linker I used many moons ago, you would link the library, and it would search the library for modules that the (partially) linked program needed, and pull in JUST those modules. It had the downside that you might need to link the same library two or three times, if the modules you pulled in linked to further modules in the same library, but it had the upside that if you only wanted a couple of modules from the library, you only GOT a couple of modules.

And by seeing which modules were linked, you knew which modules to vet and which ones to ignore.

That's the other problem with "thousands of LOC" dependencies - do you even depend on them? Would you be better off without them? Does your project even call them?

Cheers,
Wol

Sick of "many dependencies" framing

Posted Feb 11, 2026 13:09 UTC (Wed) by NAR (subscriber, #1313) [Link] (1 responses)

The larger dependencies might have more maintainers, each maintaining a specific part of the large dependency, so even though it's one library, you might need to interact with multiple maintainers. On the other hand some smaller dependencies might have the same maintainer. The number of maintainers should scale with the amount of code, not the way it's organized.

Sick of "many dependencies" framing

Posted Feb 12, 2026 10:07 UTC (Thu) by taladar (subscriber, #68407) [Link]

But the way it is organized can make it a lot more transparent or obscure who actually maintains what, which bits are actually maintained,...

Sick of "many dependencies" framing

Posted Feb 11, 2026 10:43 UTC (Wed) by Karellen (subscriber, #67644) [Link] (8 responses)

With five dependencies of 100kLOC each, you can ask "How trustworthy do these projects and their maintainers seem"?

You can look at the histories of the projects. You can see how long the projects have been going, how frequently releases are made. You can see if they just claim to follow semver, or actually do so. And, when they do make a brown paper bag release, what do they do next?

To answer your concerns, you can examine how well maintained 5 dependencies are. You can check the documentation of 5 dependencies - if it's well-written, and updated with every release? You can look at the testing infrastructure and see how the project talks about it in the forums, and see how seriously it's taken.

How do they handle security issues? Do they have a history of responding in a timely manner? Do they fix the issue, rather than trying to hand-wave it away or attacking the reporter? Do they apply security updates to LTS branches? Do they have LTS branches?

You can check the licensing. Are the licenses of these five dependencies compatible with each other, and with what you want to do?

With 5 dependencies, you can look at all of them. You can tell if they're 95% untested cruft that no-one dares touch. It's possible to find answers to all these questions.

Of course, being able to find those answers doesn't guarantee you'll like them. But you *can* know. You can assess the amounts of risk you're exposing yourself to. You can make trade-offs. You can make an informed decision about whether to use one dependency over another.

If you have 100 dependencies of 5kLOC each, I don't see how you can answer those questions in any meaningful way. I think it's more likely you stop really asking them in the first place. Or even stop considering that they are questions it's even possible to answer.

I do not understand how you might think you could have *more* information about the state of 100 codebases, than you could about 5. That just doesn't track for me.

Sick of "many dependencies" framing

Posted Feb 11, 2026 11:55 UTC (Wed) by pizza (subscriber, #46) [Link]

>With 5 dependencies, you can look at all of them. You can tell if they're 95% untested cruft that no-one dares touch. It's possible to find answers to all these questions.
>If you have 100 dependencies of 5kLOC each, I don't see how you can answer those questions in any meaningful way.

I think it's important to re-iterate that "number of dependencies" matters far more than "kLOC of code" -- eg the paperwork (not to mention the _actual_ work) that you need for CRA compliance scales linearly based on the former, but not the latter.

Sick of "many dependencies" framing

Posted Feb 11, 2026 15:23 UTC (Wed) by farnz (subscriber, #17727) [Link]

My lived experience is that you're wrong. You can't examine, realistically, how well maintained the parts of a big dependency that you care about are maintained, because the project as a whole is well-maintained, and the parts you care about may well "look" maintained because someone's doing build fixes and the like - see the HIPPI support in the Linux kernel as an example, which "looked" maintained because it was getting some fixes, but was in fact unmaintained for all practical purposes.

Remember that practically, it's not 5 dependencies of 100 kLOC each versus 100 dependencies of 5 kLOC each, but 5 dependencies of 1,000 kLOC, where you rely on 100 kLOC of the dependency, versus 100 dependencies of 5 kLOC each, where you rely on 4 kLOC of each dependency. It sure is nice that the 90% you don't use is well-documented and well-maintained, but you need to answer the question not for the dependency as a whole, but for the part you use, to have an answer that's meaningful.

Sure, it's great that all the parts shared across platforms are well-maintained, and the Apple iOS using teams make build fixes to the Android build, but if you're using it on Android, you don't want to discover that the Android build is effectively unmaintained, and has critical vulnerabilities that they're going to respond to with "eh, we don't actually care about Android that much - switch to Apple products" when you hit them.

Sick of "many dependencies" framing

Posted Feb 11, 2026 15:25 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

Hmm. I think a metric that may matter more (but is far harder to measure) is how widely *used* a given dependency is ("impact"?). GTK2/3 may be *large*, but the ecosystem has largely moved on, so any problems can lay dormant for longer. Large projects are more likely to have a broad base of users. However, small dependencies can also be "as large as needed" and solve their problem well. And if the ecosystem as a whole uses it widely, any problems are *far* more likely to be noticed in a timely manner.

With tools like `crev`[1] and `cargo-vet` (and similar for other ecosystems), this feels like it'd be easier to get a grip on in a measurable way. "Just" need to find even more review time in everyone's schedules…

[1] https://github.com/crev-dev/crev/

Sick of "many dependencies" framing

Posted Mar 11, 2026 9:39 UTC (Wed) by sammythesnake (guest, #17693) [Link]

> And if the ecosystem as a whole uses it widely, any problems are *far* more likely to be noticed in a timely manner.

Open question: how does the scaling of "popularity" -> "quick spotting/fixing of problems" compare too the scaling of "popularity" -> "tasty target for malicious actors"...?

If the tastiness overtakes the benefits of problem spotting/fixing, then there's a net downside. I suspect neither scales neatly. There are probably discontinuities, such as when a specific project takes a dependency on - suddenly a particularly tasty target, or (hopefully) a particularly diligent project comes into scope. My bet would be on the former being the more significant. I also imagine the benefit is a diminishing returns scenario, whereas tastiness scales superlinearly, so the downside probably inevitably overtake the benefits at some point.

Related to that, the *diversity* of the uses matters a lot - if everyone else using it makes similar assumptions, that popularity doesn't imply much for a different use case...

Sick of "many dependencies" framing

Posted Feb 11, 2026 15:31 UTC (Wed) by mb (subscriber, #50428) [Link] (3 responses)

>If you have 100 dependencies of 5kLOC each, I don't see how you can answer those questions in any meaningful way.

https://crates.io/crates/cargo-vet

Sick of "many dependencies" framing

Posted Feb 11, 2026 23:07 UTC (Wed) by Karellen (subscriber, #67644) [Link] (2 responses)

Wouldn't that work just as well for a few large dependencies if, for some reason, you didn't want to do the vetting yourself though?

I still don't see how many small dependencies is an improvement.

Sick of "many dependencies" framing

Posted Feb 12, 2026 2:44 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I think there's a higher chance that more people will review a small library than anyone will review "Qt" and give it a stamp of approval like this (beyond "it's got a lot of development behind it and Qt Company's track record is pretty good"). At which point, you're back to `cargo-vibes` instead.

Sick of "many dependencies" framing

Posted Feb 12, 2026 9:53 UTC (Thu) by farnz (subscriber, #17727) [Link]

You run into human nature again with the big dependency.

If you're using (say) Qt 7 for a Wayland application running on the Linux kernel, you don't benefit from Qt 7 having thousands of reviews scoped tightly to the Win32 code in Qt; you care about reviews of the Linux/Wayland code, not the Windows code. But the reviewers may well not bother to tell you that their review is scoped to the Win32 code - after all, they're reviewing Qt 7 as they use it, and they're assuming that you know that everyone uses Win32, because that's their life experience.

This puts you at high risk of the "thousands of irrelevant reviews" problem; you see lots of published reviews, and assume that the codebase is well-reviewed. But, in fact, those reviews cover the 80% of the codebase that everyone else uses, and not the 20% that's critical to your project.