6 ms·
This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purpos
by ncruces 1y ago
This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments.
Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-parties.
- zwnow 1y agoUnfortunately that's almost the whole industry. Every software project I've seen has an uncountable amount of dependencies. No matter if npm, cargo, go packages, whatever you name.
- AnonymousPlanet 1y agoEvery place I ever worked at made sure to curate the dependencies for their main projects. Heck, in some cases that was even necessary for certifications. Web dev might be a wild west, but as soon as your software is installed on prem by hundreds or thousands of paying customers the stakes change.
- zwnow 1y agoCurating dependencies won't prevent all supply chain attacks though
- jen20 1y agoZero-external-dependency Go apps are far more feasible than Rust or Node, simply because of the size and quality of the standard library.
- ncruces 1y agoJust the other day someone argued with me that it was reasonable for Limbo (the SQLite Rust rewrite) to have 3135 dependencies (of those, 1313 Rust dependencies). https://github.com/tursodatabase/turso/network/dependencies https://github.com/tursodatabase/turso/network/dependencies
- whstl 1y agoThis is incredible. At this rate, there's a non-zero chance that one of the transitive dependencies is SQLite itself.
- wolvesechoes 1y agoBut it will be safe SQlite, called from Rust.
- Meneth 1y ago3 different types of sqlite, 14 different versions total: https://github.com/tursodatabase/turso/network/dependencies?q=sqlite https://github.com/tursodatabase/turso/network/dependencies?...
- aw1621107 1y agoLooks like they're all pulled in as dev dependencies. libsqlite3-sys gets pulled in by rusqlite, which is used by core_tester, limbo_sim, write-throughput-sqlite, and as a dev_dependency for turso_core.
- Ygg2 1y agoYeah. You have dev dependencies in there, those alone will increase number of dependencies by ~500, without ending up in the final product. Those numbers are way off their actual number.
- the8472 1y agoRather than adding friction there is something else that could benefit from having as little friction as sharing code: publishing audits/reviews.
- Pet_Ant 1y agoI find that the issue is much more often not updating dependencies often enough with known security holes, than updating too often and getting hit with a supply-chain malware attack.
- sgc 1y agoThere have been several recent supply chain attacks that show attackers are taking advantage of this (previously sensible) mentality. So it is time to pivot and come up with better solutions before it spirals out of control.
- IgorPartola 1y agoA model that Linux distros follow would work to an extent: you have developed of packages and separate maintainers who test and decide to include or exclude packages and versions of packages. Imagine a JS distro which includes the top 2000 most popular libraries that are all known to work with each other. Your project can pull in any of these and every package is cryptographically signed off on by both the developers and the maintainer. Vulnerabilities in Linux distro packages obviously happen. But a single developer cannot push code directly into for example Debian and compromise the world.
- dboreham 1y agoNot updating is the other side of the same problem: library owners feel it is ok to make frequent backwards-compatibility breaking changes, often ignoring semver conventions. So consumers of their libraries are left with the choice to pin old insecure versions or spend time rewriting their code (and often transitive dependency code too) to keep up. This is what happens when nobody pays for anything and nobody feels they have a duty to do good work for free.
- banku_brougham 1y ago>This is what happens when nobody pays for anything and nobody feels they have a duty to do good work for free. Weirdly, some of the worst CVE I can think of were with enterprize software.
- computerex 1y agoBe that as it may, a system that can fail catastrophically will. Security shouldn't be left to choice.
- rectang 1y agoIt's not unreasonable to trust large numbers of trustworthy dependency authors. What we lack are the institutions to establish trust reliably. If packages had to be cryptographically signed by multiple verified authors from a per-organization whitelist in order to enter distribution, that would cut down on the SPOF issue where compromising a single dev is enough to publish multiple malware-infested packages.
- dboreham 1y agoProblem is that beyond some threshold number of authors, the probability they're all trustworthy falls to zero.
- rectang 1y agoIt's true that smuggling multiple identities into the whitelist is one attack vector, and one reason why I said "cut down" rather than "eliminate". But that's not easy to do for most organizations. For what it's worth, back when I was active at the ASF we used to vote on releases — you needed at least 3 positive votes from a whitelist of approved voters to publish a release outside the org and there was a cultural expectation of review. (Dunno if things have changed.) It would have been very difficult to duplicate this NPM attack against the upstream ASF release distribution system.
- WesolyKubeczek 1y ago"Find large numbers of trustworthy dependency authors in your neighborhood!" "Large numbers of trustworthy dependency authors in your town can't wait to show you their hottest code paths! Click here for educational livecoding sessions!"
- rectang 1y agoI don't understand your critique. Establishing a false identity well enough to fool a FOSS author or organization is a lot of work. Even crafting a spear phishing email/text campaign doesn't compare to the effort you'd have to put in to fool a developer well enough to get offered publishing privileges. Of course it's possible, but so are beat-them-with-a-five-dollar-wrench attacks.
- zelphirkalt 1y agoSee auto update bots on Github. https://docs.github.com/en/code-security/dependabot/dependabot-version-updates https://docs.github.com/en/code-security/dependabot/dependab... And since Github does it, it must be a good thing, right? Right???
- worik 1y ago> This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them I do not know about NPM. But in Rust this is common practice. Very hard to avoid. The core of Rust is very thin, to get anything done typically involves dozens of crates, all pulled in at compile time from any old developer implicitly trusted.
- hedora 1y agoThe same is true for go and for java.
- ricardobeat 1y agoYou can write entire applications in Go without resorting to any dependencies, the std lib is quite complete. Most projects will have a healthy 5-20 dependencies though, with very little nested modules.
- fennecfoxy 1y ago>absolve developers Doesn't this ultimately go all the way up to the top? You have 2 devs: one who mostly writes their own code, only uses packages that are audited etc; the other uses packages willy nilly. Who do you think will be hired? Who do you think will be able to match the pace of development that management and executives demand?