7 ms·

It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'

by sph 1y ago

It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. Ambivalent about Go: they have a semblance of packaging system, but nothing so reckless like allowing third-party tarballs uploaded in the cloud to effectively run code on the dev's machine.

fouronnes3 1y ago
Surely in this case the problem is a technical one, and with more work towards a better security model and practices we can have the best of both worlds, no?
dotancohen 1y ago
Historically, arguments of "it's popular so that's why it's attacked" have not held up. Notable among them was addressing Windows desktop security vulnerabilities. As Linux and Mac machines became more popular, not to mention Android, the security vulnerabilities in those burgeoning platforms never manifested to the extent that they were in Windows. Nor does cargo or pip seem to be infected with these problems to the extent that npm is.
- mschuster91 1y ago
  > Nor does cargo or pip seem to be infected with these problems to the extent that npm is. Easy reason. The target for malware injections is almost always cryptocurrency wallets and cloud credentials (again, mostly to mine cryptocurrencies). And the utter utter majority of stuff interacting with crypto and cloud, combined with a lot of inexperienced juniors who likely won't have the skill to spot they got compromised, is written in NodeJS.
- whizzter 1y ago
  Compared to the JS ecosystem and number of users both Python and Rust are puny, also the the NPM ecosystem also allowed by default for a lot of post-install actions since they wanted to enable a smooth experience with compiling and installing native modules (Not entirely sure how Cargo and PIP handles native library dependencies). As for Windows vs the other OS's, yes even the Windows NT family grew out of DOS and Win9x and tried to maintain compatiblity for users over security up until it became untenable. So yes, the base _was_ bad when Windows was dominant but it's far less bad today (why people target high value targets via NPM,etc since it's an easier entry-point). Android/iOS is young enough that they did have plenty of hindsight when it comes to security and could make better decisions (Remember that MS tried to move to UWP/Appx distribution but the ecosystem was too reliant on newer features for it to displace the regular ecosystem). Remember that we've had plenty of annoyed discourse about "Apple locking down computers" here and on other tech forums when they've pushed notarization. I guess my point is that, people love to bash on MS but at the same time complain about how security is affecting their "freedoms" when it comes to other systems (and partly MS), MS is better at the basics today than they were 20-25 years ago and we should be happy about that.
  - skydhash 1y ago
    You can have security without having a walled garden. By trusting the user with the key of their own property.
    - whizzter 1y ago
      You mean like the developers holding the npm-publishing keys that just allowed a worm to spread?
      - skydhash 1y ago
        No. By NPM not allowing any package to run code on the developer's machine. I can trust npm (the software), but not the library. It's a very weird choice to just allow any package to run post install script. Especially when there's little to none verification done on npmjs side. Developers can feel free to not secure their computer or sell their keys. But that not means npm should allow straight code push from their computers to everyone that has downloaded their library.
vintagedave 1y ago
I believe you, in that package management with dependencies without security mitigation is both convenient and dangerous. And I certainly agree this could happen for other package managers as well. My real worry, for myself re the parent comment is, it's just a web frontend. There are a million other ways to develop it. Sober, cold risk assessment is: should we, or should we have, and should anyone else, choose something npm-based for new development? Ie not a question about potential risk for other technologies, but a question about risk and impact for this specific technology.
progbits 1y ago
Agreed with the first half, but giving up on convenient packaging isn't the answer. Things like cargo-vet help as does enforcing non-token auth, scanning and required cooldown periods.
tjpnz 1y ago
In the early days the Node ecosystem adopted (from Unix) the notion that everything has to be its own micro package. Not only was there a failure to understand what it was actually talking about, but it was never a good fit for package management to begin with. I understand that there's been some course correction recently (zero dependency and minimal dependency libs), but there are still many devs who think that the only answer to their problem is another package, or that they have to split a perfectly fine package into five more. You don't find this pattern of behavior outside of Node.
- sph 1y ago
  > In the early days the Node ecosystem adopted (from Unix) the notion that everything has to be its own micro package. The medium is the message. If a language creates a very convenient package manager that completely eliminates the friction of sharing code, practically any permutation of code will be shared as a library. As productivity is the most important metric for most companies, devs will prefer the conveniently-shared third-party library instead of implementing something from scratch. And this is the result. I don't believe you can have packaging convenience and avoiding dependency hell. You need some amount of friction.
  - skydhash 1y ago
    It’s not even the convenience. It’s about trust. Npm makes it so that as soon as you add something to the dependency list, you trust the third party so completely you’re willing to run their code on your system as soon as they push an update. It’s essentially remote execution a la carte.
rafaelmn 1y ago
There are ecosystems that have package managers but also well developed first party packages. In .NET you can cover a lot of use cases simply using Microsoft libraries and even a lot of OSS not directly a part of Microsoft org maintained by Microsoft employees.
- CharlieDigital 1y ago
  2020 State of the Octoverse security report showed that .NET ecosystem has on average the lowest number of transitive dependencies. Big part of that is the breadth and depth of the BCL, standard libraries, and first party libraries.
  - CodesInChaos 1y ago
    The .NET ecosystem has been moving towards a higher number of dependencies since the introduction of .NET Core. Though many of them are still maintained by Microsoft.
    - WorldMaker 1y ago
      The "SDK project model" did a lot to reduce that back down. They did break the BCL up into a lot of smaller packages to make .NET 4.x maintenance/compatibility easier, and if you are still supporting .NET 4.x (and/or .NET Standard), for whatever reason, your dependency list (esp. transitive dependencies) is huge, but if you are targeting .NET 5+ only that list shrinks back down and the BCL doesn't show up in your dependency lists again. Even some of the Microsoft.* namespaces have properly moved into the BCL SDKs and no longer show up in dependency lists, even though Microsoft.* namespaces originally meant non-BCL first-party.
    - int_19h 1y ago
      I think first-party Microsoft packages ought to be a separate category that is more like BCL in terms of risk. The main reason why they split them out is so that they can be versioned separately from .NET proper.
- johannesrexx 1y ago
vachina 1y ago
Node is the embodiment of move and break things. Probably will not build anything that should last more than a few months on node.
testdelacc1 1y ago
I hate to be the guy saying AI will solve it, but this is a case where AI can help. I think in the next couple of years we’ll see people writing small functions with Claude/codex/whatever instead of pulling in a dependency. We might or might not like the quality of software we see, but it will be more resistant to supply chain attacks.
- viraptor 1y ago
  I wonder what the actual result will be. LLMs can generate functions quickly, but they're also keen to include packages without asking. I've had to add a "don't add new dependencies unless explicitly asked" to a few project configs.
- brigandish 1y ago
  An approach I learnt from a talk posted to HN (I forget the talk, not the lesson) is to not depend on the outside project for its code, just lift that code directly in to your project, but to rely on it for the tests, requiring/importing it etc when running your own tests. That protects you from a lot of things (this kind of attack was not mentioned, afaic recall) but doesn’t allow bugs found by the other project to be missed either.
- short_sells_poo 1y ago
  How is this going to solve the supply chain attack problem at all though? It just obfuscates things even more, because once an LLM gets "infected" with malicious code, it'll become much more difficult to trace where it came from. If anything, blind reliance on LLMs will make this problem much worse.
- delaminator 1y ago
  For sure. I don't think the software ecosystem has come to terms with how things are going to change. Libraries will be providing raw tools like - Sockets, Regex Engine, Cryptography, Syscalls, specific file format libraries LLMs will be building the next layer. I have build successful running projects now in Erlang, Scheme, Rust - I know the basic syntax of two of those but I couldn't write my deployed software in any of them in the couple of hours of prompting. The scheme it had to do a lot of code from first principles and warned me how laborious it would be - "I don't care, you are doing it." I have tools now I could not have imagined I could build in a reasonable time.
larusso 1y ago
I agree partly. I love cargo and can’t understand why certain things like package namespaces and proof of ownership isn’t added at a minimum. I was mega annoyed when I had to move all our Java packages from jcenter, which was a mega easy setup and forget affair, to maven central. There I suddenly needed to register a group name (namespace mostly reverse domain) and proof that with a DNS entry. Then all packages have to be signed etc. In the end it was for this time way ahead. I know that these measures won’t help for all cases. But the fact that at least on npm it was possible that someone else grabs a package ID after an author pulled its packages is kind of alarming. Dependency confusion attacks are still possible on cargo because the whole - vs _ as delimiter wasn’t settled in the beginning. But I don’t want to go away from package managers or easy to use/sharable packages either.
- kibwen 1y ago
  > But the fact that at least on npm it was possible that someone else grabs a package ID after an author pulled its packages is kind of alarming. Since your comment starts with commentary on crates.io, I'll note that this has never been possible crates.io. > Dependency confusion attacks are still possible on cargo because the whole - vs _ as delimiter wasn’t settled in the beginning. I don't think this has ever been true. AFAIK crates.io has always prevented registering two different crates whose names differ only in the use of dashes vs underscores. > package namespaces See https://github.com/rust-lang/rust/issues/122349 https://github.com/rust-lang/rust/issues/122349 > proof of ownership See https://github.com/rust-lang/rfcs/pull/3724 https://github.com/rust-lang/rfcs/pull/3724 and https://blog.rust-lang.org/2025/07/11/crates-io-development-update-2025-07/#trusted-publishing https://blog.rust-lang.org/2025/07/11/crates-io-development-...
  - larusso 1y ago
    You are right. I remembered it wrong. https://rust-lang.github.io/rfcs/0940-hyphens-considered-harmful.html?utm_source=chatgpt.com https://rust-lang.github.io/rfcs/0940-hyphens-considered-har... Was from 2015 and the other discussions I remember were around default style and that cargo already blocks a crate when normalized name is equal.
  - 1y ago
moritonal 1y ago
Not knowing that much about apt, isn't _any_ package system vulnerable, and purely a question of what guards are in place and what rights are software given upon install?
- viraptor 1y ago
  It's not the packaging tech. Apt will typically mean a Debian-based distro. That means the packages are chosen by the maintainers and updated only during specific time periods and tested before release. Even if the underlying software gets owned and replaced, the distro package is very unlikely to be affected. (Unless someone spent months building trust, like xz) But the basic takeover... no, it usually won't affect any Debian style distro package, due to the release process.
  - trollbridge 1y ago
    Given the years (or decades) it takes updates to happen in Debian stable, it’s immune to supply chain attacks. You do get to enjoy vulnerabilities that have been out for years, though.
    - FergusArgyll 1y ago
      Security updates are basically immediate, even on stable flavors
    - alt227 1y ago
      > it’s immune to supply chain attacks Thats a strong statement that I can see aging very badly.
TheFlyingFish 1y ago
I've worried about this for a while with Rust packages. The total size of a "big" Rust project's dependency graph is pretty similar to a lot of JS projects. E.g. Tauri, last I checked, introduces about 600 dependencies just on its own. Like another commenter said, I do think it's partially just because dependency management is so easy in Rust compared to e.g. C or C++, but I also suspect that it has to do with the size of the standard library. Rust and JS are both famous for having minimal standard libraries, and what do you know, they tend to have crazy-deep dependency graphs. On the other hand, Python is famous for being "batteries included", and if you look at Python project dependency graphs, they're much less crazy than JS or Rust. E.g. even a higher-level framework like FastAPI, that itself depends on lower-level frameworks, has only a dozen or so dependencies. A Python app that I maintain for work, which has over 20 top-level dependencies, only expands to ~100 once those 20 are fully resolved. I really think a lot of it comes down to the standard library backstopping the most common things that everybody needs. So maybe it would improve the situation to just expand the standard library a bit? Maybe this would be hiding the problem more than solving it, since all that code would still have to be maintained and would still be vulnerable to getting pwned, but other languages manage somehow.
- wongarsu 1y ago
  I wouldn't call the Rust stdlib "small". "Limited" I could agree with. On the topics it does cover, Rust's stdlib offers a lot. At least on the same level as Python, at times surpassing it. But because the stdlib isn't versioned it stays away from everything that isn't considered "settled", especially in matters where the best interface isn't clear yet. So no http library, no date handling, no helpers for writing macros, etc. You can absolutely write pretty substantial zero-dependency rust if you stay away from the network and async Whether that's a good tradeoff is an open question. None of the options look really great
  - deleted 1y ago
    [deleted]
  - galangalalgol 1y ago
    Network without async works fine in std. However, rand, serde, and num_traits always seem to be present. Not sure why clap isn't std at this point.
mschuster91 1y ago
> The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. Ambivalent about Go: they have a semblance of packaging system, but nothing so reckless like allowing third-party tarballs uploaded in the cloud to effectively run code on the dev's machine. The alternative that C/C++/Java end up with is that each and every project brings in their own Util, StringUtil, Helper or whatever class that acts as a "de-facto" standard library. I personally had the misfortune of having to deal with MySQL [1], Commons [2], Spring [3] and indirectly also ATG's [4] variants. One particularly unpleasant project I came across utilized all four of them, on top of the project's own "Utils" class that got copy-and-paste'd from the last project and extended for this project's needs. And of course each of these Utils classes has their own semantics, their own methods, their own edge cases and, for the "organically grown" domestic class that barely had tests, bugs. So it's either a billion "small gear" packages with dependency hell and supply chain issues, or it's an amalgamation of many many different "big gear" libraries that make updating them truly a hell on its own. [1] https://jar-download.com/artifacts/mysql/mysql-connector-java/5.1.30/source-code/com/mysql/jdbc/StringUtils.java https://jar-download.com/artifacts/mysql/mysql-connector-jav... [2] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html https://commons.apache.org/proper/commons-lang/apidocs/org/a... [3] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/util/StringUtils.html https://docs.spring.io/spring-framework/docs/current/javadoc... [4] https://docs.oracle.com/cd/E55783_02/Platform.11-2/apidoc/atg/core/util/StringUtils.html https://docs.oracle.com/cd/E55783_02/Platform.11-2/apidoc/at...
- sph 1y ago
  That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here. And what is wrong with writing your own util library that fits your use case anyway? In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency. No one sane will add a third-party git submodule, wire it to the main Makefile, just to left-pad a string.
  - 1y ago
gnfargbl 1y ago
I'm a huge Go proponent but I don't know if I can see much about Go's module system which would really prevent supply-chain attacks in practice. The Go maintainers point [1] at the strong dependency pinning approach, the sumdb system and the module proxy as mitigations, and yes, those are good. However, I can't see what those features do to defend against an attack vector that we have certainly seen elsewhere: project gets compromised, releases a malicious version, and then everyone picks it up when they next run `go get -u ./...` without doing any further checking. Which I would say is the workflow for a good chunk of actual users. The lack of package install hooks does feel somewhat effective, but what's really to stop an attacker putting their malicious code in `func init() {}`? Compromising a popular and important project in this way would likely be noticed pretty quickly. But compromising something widely-used but boring? I feel like attackers would get away with that for a period of time that could be weeks. This isn't really a criticism of Go so much as an observation that depending on random strangers for code (and code updates) is fundamentally risky. Anyone got any good strategies for enforcing dependency cooldown? [1] https://go.dev/blog/supply-chain https://go.dev/blog/supply-chain
- _cenw 1y ago
  The Go standard library is a lot more comprehensive and usable than Node, so you need less dependencies to begin with.
- devttyeu 1y ago
  In Go you know exactly what code you’re building thanks to gosum, and it’s much easier to audit changed code after upgrading - just create vendor dirs before and after updating packages and diff them; send to AI for basic screening if the diff is >100k loc and/or review manually. My projects are massive codebases with 1000s of deps and >200MB stripped binaries of literally just code, and this is perfectly feasible. (And yes I do catch stuff occasionally, tho nothing actively adversarial so far) I don’t believe I can do the same with Rust.
  - WD-42 1y ago
    cargo vendor
eptcyka 1y ago
Go is just as bad.
- Yasuraka 1y ago
  Nope. Know the difference.
  - eptcyka 1y ago
    How is Go any worse or better than Rust when it comes to the ease of adding dependencies?
    - Yasuraka 1y ago
      I read your comment as in, comparing to node, my bad. With regards to Rust, crates are packages which may include opaque binaries, e.g. serde_derive, and the stdlib is weak, so imports of thousands of lines of code are basically necessary for otherwise fundamental features like async. It's probably easier to add dependencies in Go, but in the end people/projects don't.
zenmac 1y ago
Just a last month someone was trying to figure the cargo tree on which Rust package got imported implicitly via which package. This will totally happen in rust as well as long as you use some kind of package manager. Go for zero or less decencies.
- actionfromafar 1y ago
  less?
  - beeb 1y ago
    decencies?
  - troupo 1y ago
    Make it so others depend on you? :)
  - officialchicken 1y ago
    Roll your own standard library - or go without one entirely `#![no_std]`
- galangalalgol 1y ago
  It already did happen. It propogated via build.rs as well. But as I said elsewhere, ut doesn't help you to forgo dependencies part of rust tooling itself.
dwroberts 1y ago
I think this is right about Rust and Cargo, but I would say that Rust has a major advantage in that it implements frozen + offline mode really well (which if you use, obviously significantly decreases the risks). Any time I ever did the equivalent with NPM/node world it was basically unusable or completely impractical
- bhouston 1y ago
  Pnpm (a very popular npm replacement) makes completely locked packages easy and natural and ultra fast: https://pnpm.io/cli/install https://pnpm.io/cli/install Benchmarks: https://pnpm.io/benchmarks https://pnpm.io/benchmarks
  - 15155 1y ago
    pnpm is so laughably terrible compared to Cargo it's not even comparable in the same breath.
    - bhouston 1y ago
      Why specifically? Your comment isn't very informative. Anyhow, here a Claude.ai comparison: https://claude.ai/share/72d2c34c-2c86-44c4-99ec-2a638f10e3f0 https://claude.ai/share/72d2c34c-2c86-44c4-99ec-2a638f10e3f0
      - 15155 1y ago
        Because it doesn't perform as advertised: wild amounts of inconsistencies in behavior (within and between versions), performance issues (pnpm exec adds 15s to all shebang'd execution time over npm/yarn/bun/etc.), etc. Version-to-version stability has been traditionally bad - it's half-baked software. Claude doesn't know this, of course, because it can only read superficial summaries posted on the internet and has zero real experience actually using this dumpster fire.
Davidbrcz 1y ago
Don't worry about C or C++, we create the vulnerabilities ourselves !
- GuB-42 1y ago
  I get the joke, but that makes me think. What is worse between writing potentially vulnerable code yourself and having too many dependencies. Finding vulnerabilities and writing exploits is costly, and hackers will most likely target popular libraries over your particular software, much higher impact, and it pays better. Dependencies also tend to do more than you need, increasing the attack surface. So your C code may be worse in theory, but it is a smaller, thus harder to hit target. It is probably an advantage against undiscriminating attacks like bots and a downside against targeted attacks by motivated groups.
trollbridge 1y ago
An open question is why PyPI doesn’t have the same problem.
- pxc 1y ago
  PyPI is also subject to supply chain attacks. What do you mean?
randomint64 1y ago
Indeed, Rust's supply chains story is an absolute horror, and there are countless articles explaining what should be done instead (e.g. https://kerkour.com/rust-stdx https://kerkour.com/rust-stdx) TL;DR: ditch crates.io and copy Go with decentralized packages based directly on and an extended standard library. Centralized package managers only add a layer of obfuscation that attackers can use to their advantage. On the other hand, C / C++ style dependency management is even worse than Rust's... Both in terms of development velocity and dependencies that never get updated.
- Ygg2 1y ago
  > countless articles explaining what should be done instead (e.g. https://kerkour.com/rust-stdx https://kerkour.com/rust-stdx) Don't make me tap the sign: https://news.ycombinator.com/item?id=41727085#41727410 https://news.ycombinator.com/item?id=41727085#41727410 > Centralized package managers only add a layer of obfuscation that attackers can use to their advantage. They add a layer of convenience. C/C++ are missing that convenience because they aren't as composable and have a long tail of pre-package manager projects. Java didn't start with packages, but today we have packages. Same with JS, etc.
  - eichin 1y ago
    Or from another angle, dpkg/apt is the package manager for C/C++ ...
    - Ygg2 1y ago
      Yeah, but it's not immune to supply chain attacks. Counting on maintainers of dpkg is not that different from counting on maintainers of random crate package.
hyperpape 1y ago
Supply chain attacks are scary because you do everything "right", but the ecosystem still compromises you. But realistically, I think the sum total of compromises via package managers attacks is much smaller than the sum total of compromises caused by people rolling their own libraries in C and C++. It's hard to separate from C/C++'s lack of memory safety, which causes a lot of attacks, but the fact that code reuse is harder is a real source of vulnerabilities. Maybe if you're Firefox/Chromium, and you have a huge team and invest massive efforts to be safe, you're better off with the low-dependency model. But for the median project? Rolling your own is much more dangerous than NPM/Cargo.
newpavlov 1y ago
While I agree that dependency tree size can be sometimes a problem in Rust, I think it often gets overblown. Sure, having hundreds of dependencies in a "simple" project can be scary, but: 1) No one forces you to use dependencies with large number of transitive dependencies. For example, feel free to use `ureq` instead of `reqwest` pulling the async kitchen sink with it. If you see an unnecessary dependency, you could also ask maintainers to potentially remove it. 2) Are you sure that your project is as simple as you think? 3) What matters is not number of dependencies, but number of groups who maintain them. On the last point, if your dependency tree has 20 dependencies maintained by the Rust lang team (such as `serde` or `libc`), your supply chain risks are not multiplied by 20, they stay at one and almost the same as using just `std`.
- galangalalgol 1y ago
  On your last note, I wish they would get on that signed crate subset. Having the same dependency tree as cargo, clippy, and rustc isn't increasing my risk. Rust has already had a supply chain attack propagating via build.rs some years ago. It was noticed quickly, so staying pinned to the oldest thing that worked and had no cve pop in cargo audit is a decent strategy. The remaining risk is that some more niche dependency you use is and always has been compromised.
- assbuttbuttass 1y ago
  Is serde maintained by the Rust team? I thought it was basically a one-man show owned by dtolnay
rock_artist 1y ago
Using C++ daily, whenever I do js/ts are some javascript variant, since I don't use it daily, and update becomes a very complex task. frameworks and deps change APIs very frequently. It's also very confusing (and I think those attack vectors benefit exactly from that), since you have a dependency but the dep itself dependent on another dep version. Building basic CapacitorJS / Svelte app as an example, results many deps. It might be a newbie question, but, Is there any solution or workflow where you don't end up with this dependency hell?
- smt88 1y ago
  There's no solution. The JS world is just nonstop build and dependency hell. Being incredibly strict with TS compiler and linter helps a bit.
- threetonesun 1y ago
  Don't use a framework? Loading a JS script on a page that says "when a update b" hasn't changed much in about 20 years. Maybe I'm being a bit trite but the world of JavaScript is not some mysterious place separate from all other web programming, you can make bad decisions on either side of the stack. These comments always read like devs suddenly realizing the world of user interactions is more complicated and has more edge cases than they think.
woodruffw 1y ago
It’ll probably happen eventually with Rust, but ecosystem volume and informal packaging processes / a low barrier to entry seem to be significant driver in the npm world. (These are arguably good things in other contexts.)
JD557 1y ago
I have a similar opinion but I think Java's model with maven and friends hits the sweet spot: - Packages are always namespaced, so typosquating is harder - Registries like Sonatype require you to validate your domain - Versions are usually locked by default My professional life has been tied to JVM languages, though, so I might be a bit biased. I get that there are some issues with the model, especially when it comes to eviction, but it has been "good enough" for me. Curious on what other people think about it.
- oftenwrong 1y ago
  Maven does not support "scripts" as NPM does, such as the pre-install script used for this exploit. With scripts enabled, the mere act of downloading a dependency requires a high degree of trust in it.
  - 15155 1y ago
    Downloading a dependency also requires a high degree of trust in whatever transitive dependencies that a trusted dependency decides to pull in.
alextingle 1y ago
Every time I look at a new project, my face falls when it's written in Rust. I simply don't trust a system that pulls in gigabytes of god-knows-what off the cloud, and compiles it on my box. It's a real barrier to entry, for me. When I download a C project, I know that it only depends on my system libraries - which I trust because I trust my distro. Rust seems to expect me to take a leap in the dark, trusting hundreds of packagers and their developers. That might be fine if you're already familiar with the Rust ecosystem, but for someone who just wants to try out a new program - it's intimidating.
- cyphar 1y ago
  On Debian you can use the local registry for Rust which is backed by packages. Though I will say, even as someone who works at a company that sells Linux distributions (SUSE), while the fact we have an additional review step is nice, I think the actual auditing you get in practice is quite minimal. For instance, quite recently[1] the Debian package for a StarDict plugin was configured automatically upload all text selected in X11 to some Chinese servers if you installed it. This is the kind of thing you'd hope distro maintainers to catch. Though, having build scripts be executed in distribution infrastructure and shipped to everyone mitigates the risk of targeted and "dumb" attacks. C build scripts can attack your system just as easily as Rust or JavaScript ones can (in fact it's probably even easier -- look at how the xz backdoor took advantage of the inscrutability of autoconf). [1]: https://www.openwall.com/lists/oss-security/2025/08/04/1 https://www.openwall.com/lists/oss-security/2025/08/04/1
- iknowstuff 1y ago
  You don't know that about a C project. And you still don't know what lurks in its 1000th reimplementation of http header parsing.
  - alextingle 1y ago
    Well, yes I do know when a C project only depends on my system libraries, because otherwise it won't compile. That's the point. Furthermore, for the purposes of this discussion, it really doesn't matter what code there is in the C project. What's there has been put there by the people who run the project. If they are malicious, then at least I know who they are. With Rust, I'm downloading and compiling code from many, many third parties. I have no idea who they are. The potential for one of them to be malicious is much, much higher.
aa-jv 1y ago
> C/C++ .. a convenient package manager Every time I fire up "cmake" I chant a little spell that protects me from the goblins that live on the other side of FetchContent to promise to the Gods of the Repo that I will, eventually, review everything to make sure I'm not shipping poop nuggets .. just as soon as I get the build done, tested .. and shipped, of course .. but I never, ever do.
agumonkey 1y ago
do they follow the same process ? or is it harder to submit a package and vet it on rust/cargo ?
PunchyHamster 1y ago
Rust (and really, any but JS) ecosystem have a bit more "due dilligence" applied everywhere; I don't doubt someone will try to namesquat but chance of success are far smaller > The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. There was no decision in case of C/C++; it was just not a thing languages had at the time so the language itself (especially C) isn't written in a way to accommodate it nicely > Ambivalent about Go: they have a semblance of packaging system, but nothing so reckless like allowing third-party tarballs uploaded in the cloud to effectively run code on the dev's machine. Any code you download and compile is running code on dev machine; and Go does have tools to do that in compile process too. I do however like the by default namespacing by domain, there is no central repository to compromise, and forks of any defunct libs are easier to manage.
- JeremyNT 1y ago
  > Rust (and really, any but JS) ecosystem have a bit more "due dilligence" applied everywhere; I don't doubt someone will try to namesquat but chance of success are far smaller I really agree, and I feel like it's a culture difference. Javascript was (and remains) an appealing programming language for tinkerers and hobbyists, people who don't really have a lot of engineering experience. Node and npm rose to prominence as a wild west with lots of new developers unfamiliar with good practices, stuck with a programming environment that had few "batteries included," and at a time when supply chain attacks weren't yet on everybody's minds. The barriers to entry were low and, well, the ecosystem sort of reflected that. You can't wash that legacy away overnight. Rust in contrast attracts a different audience because of the language's own design objectives. Obviously none of this makes it immune, and you can YOLO install random dependencies in any programming language, but I don't think any language is ever going to suffer from this in quite the same way and to the same extent that JS has simply due to when and how the ecosystem evolved. And really, even JS today is not JS of yesteryear. Sure there are lots of bad actors and these bad NPM packages sneak in, but also... how widely are all of them used? The maturation of and standardization on certain "batteries included" frameworks rather than ad hoc piecing stuff together has reduced the liklihood of going astray.
chuckadams 1y ago
> It's not "node" or "Javascript" the problem, it's this convenient packaging model. That and the package runtime runs with all the same privileges and capabilities as the thing you're building, which is pretty insane when you think about it. Why should npm know anything outside of the project root even exists, or be given the full set of environment variables without so much as a deny list, let alone an allow list? Of course if such restrictions are available, why limit them to npm? The real problem is that the security model hasn't moved substantially since 1970. We already have all the tools to make things better, but they're still unportable and cumbersome to use, so hardly anything does.
- pas 1y ago
  pnpm (maybe yarn too?) requires explicit allowlisting of build scripts, hopefully npm will do the same eventually > security model yep, some kind of seccomp or other kind of permission system for modules would help a lot. (eg. if the 3rd party library is parsing something and its API only requires a Buffer as input and returns some object then it could be marked "pure", if it supports logging then that could be also specified, and so on)
  - chuckadams 1y ago
    For all the other things I like about yarn, it still executes build scripts willy-nilly, so I am looking at switching to pnpm. I'm sure my $work is going to love me changing up the build toolchain again... PHP's composer on the other hand requires an allowlist in the project's composer.json. I never would have thought PHP would be the one to be getting stuff like this right. Still, I think the "allow-scripts" section or whatever it's called should be named "allow-unrestricted-access-to-everything". Or maybe just stick "dangerously-" in front, I dunno, and drop it when the mechanism is capable of fine-grained privileges.
  - WorldMaker 1y ago
    Deno also requires allowlisting npm scripts. It also has a deeper permissions model in general.
poulpy123 1y ago
> The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. The safest code is the code that is not run. There is no lack of attacks targeting C/C++ code, and odin is just a hobby language for now.
riffraff 1y ago
maybe the solution is what linux & co used for many years: have a team of people who vet and package dependencies.
dijit 1y ago
> but it's only a matter of time until it'll happen on the Rust ecosystem Totally 100% agree, though tools like cargo tree make it more of a tractable problem, and running vendored dependencies is first class at least. The one I am genuinely most concerned of is Golang. The way Dependencies are handled leaves much to be desired, I'm really surprised that there haven't been issues honestly.
kunley 1y ago
Why the word "semblance" with regard to Go modules? Are you trying to say this system is lacking something?
SkiFire13 1y ago
Not having a convenient package manager doesn't mean you don't need the functionality that's otherwise offered by third-party packages, it just means that you either need other means to obtain those third-party packages (usually reducing the visibility this dependency!) or implement them yourself (sometimes this is good, but sometimes this can also be very bad for security. Your DYI code won't get as many eyes and audits as the popular third party package!). Must read: https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies
parliament32 1y ago
Agreed, rust's cargo model is basically the worst part of that ecosystem right now. I've had developers submit pretty simple cli tools with hundreds and hundreds of dependencies. I guess there wasn't any lessons learned from the state of NPM.
ratmice 1y ago
My feeling is that languages with other packing models are merely less convenient, and there is no actual tangible difference security-wise. Just take C and replace "look for writable repositories". It just takes more work and is less uniform to say write a worm that looks for writable cmake/autoconf and replicate that way. What would actually stop this is writing compilers and build systems in a way that isolates builds from one another. It's kind of stupid that all a compiler really needs is an input file, a list of dependencies, and an output file. Yet they all make it easy to root around, replicate and exfiltrate. It can be both convenient and not suffer from these style of attacks.
- skydhash 1y ago
  Not really. cmake and automake are for compiling the library, not for the downloading it. The gap between the two is what's get erased from npm. And it made worse because of the auto update set by default when `npm install` is run.
lijok 1y ago
I don’t get this I installed the package, obviously I intend to run it. How does getting pwned once I run it manually differ from getting pwned once I install it? I’m still getting pwned
- skydhash 1y ago
  NPM default installation method does not really lock down you dependencies. It allows for update when the patch number (semver) is increased. Which is why those malware bump it up. Anyone who then run `npm install` will get it and will run the code.
kpcyrd 1y ago
Out of the 789 npm packages in this incident, only 4 were ever used in any dependency tree of any Linux operating system (including Homebrew). Not in the affected versions, but ever. If your Rust software observes a big enough chunk of the computer fever dream you are likely to end up with 2-3 digit amount of Rust dependencies, but they are probably all going to be high profile ones (tokio, anyhow, reqwest, the hyper crates, ...), instead of niche ones that never make it into any operating system. This is not a silver bullet of course, but there seems to be an inverse correlation between "is part of any operating system dependency tree" and "gets compromised in an npm-like incident".

by sph 1y ago

fouronnes3 1y ago

Surely in this case the problem is a technical one, and with more work towards a better security model and practices we can have the best of both worlds, no?

dotancohen 1y ago

Historically, arguments of "it's popular so that's why it's attacked" have not held up. Notable among them was addressing Windows desktop security vulnerabilities. As Linux and Mac machines became more popular, not to mention Android, the security vulnerabilities in those burgeoning platforms never manifested to the extent that they were in Windows. Nor does cargo or pip seem to be infected with these problems to the extent that npm is.

mschuster91 1y ago
> Nor does cargo or pip seem to be infected with these problems to the extent that npm is. Easy reason. The target for malware injections is almost always cryptocurrency wallets and cloud credentials (again, mostly to mine cryptocurrencies). And the utter utter majority of stuff interacting with crypto and cloud, combined with a lot of inexperienced juniors who likely won't have the skill to spot they got compromised, is written in NodeJS.
whizzter 1y ago
Compared to the JS ecosystem and number of users both Python and Rust are puny, also the the NPM ecosystem also allowed by default for a lot of post-install actions since they wanted to enable a smooth experience with compiling and installing native modules (Not entirely sure how Cargo and PIP handles native library dependencies). As for Windows vs the other OS's, yes even the Windows NT family grew out of DOS and Win9x and tried to maintain compatiblity for users over security up until it became untenable. So yes, the base _was_ bad when Windows was dominant but it's far less bad today (why people target high value targets via NPM,etc since it's an easier entry-point). Android/iOS is young enough that they did have plenty of hindsight when it comes to security and could make better decisions (Remember that MS tried to move to UWP/Appx distribution but the ecosystem was too reliant on newer features for it to displace the regular ecosystem). Remember that we've had plenty of annoyed discourse about "Apple locking down computers" here and on other tech forums when they've pushed notarization. I guess my point is that, people love to bash on MS but at the same time complain about how security is affecting their "freedoms" when it comes to other systems (and partly MS), MS is better at the basics today than they were 20-25 years ago and we should be happy about that.
- skydhash 1y ago
  You can have security without having a walled garden. By trusting the user with the key of their own property.
  - whizzter 1y ago
    You mean like the developers holding the npm-publishing keys that just allowed a worm to spread?
    - skydhash 1y ago
      No. By NPM not allowing any package to run code on the developer's machine. I can trust npm (the software), but not the library. It's a very weird choice to just allow any package to run post install script. Especially when there's little to none verification done on npmjs side. Developers can feel free to not secure their computer or sell their keys. But that not means npm should allow straight code push from their computers to everyone that has downloaded their library.

vintagedave 1y ago

I believe you, in that package management with dependencies without security mitigation is both convenient and dangerous. And I certainly agree this could happen for other package managers as well. My real worry, for myself re the parent comment is, it's just a web frontend. There are a million other ways to develop it. Sober, cold risk assessment is: should we, or should we have, and should anyone else, choose something npm-based for new development? Ie not a question about potential risk for other technologies, but a question about risk and impact for this specific technology.

progbits 1y ago

Agreed with the first half, but giving up on convenient packaging isn't the answer. Things like cargo-vet help as does enforcing non-token auth, scanning and required cooldown periods.

tjpnz 1y ago

In the early days the Node ecosystem adopted (from Unix) the notion that everything has to be its own micro package. Not only was there a failure to understand what it was actually talking about, but it was never a good fit for package management to begin with. I understand that there's been some course correction recently (zero dependency and minimal dependency libs), but there are still many devs who think that the only answer to their problem is another package, or that they have to split a perfectly fine package into five more. You don't find this pattern of behavior outside of Node.

sph 1y ago
> In the early days the Node ecosystem adopted (from Unix) the notion that everything has to be its own micro package. The medium is the message. If a language creates a very convenient package manager that completely eliminates the friction of sharing code, practically any permutation of code will be shared as a library. As productivity is the most important metric for most companies, devs will prefer the conveniently-shared third-party library instead of implementing something from scratch. And this is the result. I don't believe you can have packaging convenience and avoiding dependency hell. You need some amount of friction.
- skydhash 1y ago
  It’s not even the convenience. It’s about trust. Npm makes it so that as soon as you add something to the dependency list, you trust the third party so completely you’re willing to run their code on your system as soon as they push an update. It’s essentially remote execution a la carte.

rafaelmn 1y ago

There are ecosystems that have package managers but also well developed first party packages. In .NET you can cover a lot of use cases simply using Microsoft libraries and even a lot of OSS not directly a part of Microsoft org maintained by Microsoft employees.

CharlieDigital 1y ago
2020 State of the Octoverse security report showed that .NET ecosystem has on average the lowest number of transitive dependencies. Big part of that is the breadth and depth of the BCL, standard libraries, and first party libraries.
- CodesInChaos 1y ago
  The .NET ecosystem has been moving towards a higher number of dependencies since the introduction of .NET Core. Though many of them are still maintained by Microsoft.
  - WorldMaker 1y ago
    The "SDK project model" did a lot to reduce that back down. They did break the BCL up into a lot of smaller packages to make .NET 4.x maintenance/compatibility easier, and if you are still supporting .NET 4.x (and/or .NET Standard), for whatever reason, your dependency list (esp. transitive dependencies) is huge, but if you are targeting .NET 5+ only that list shrinks back down and the BCL doesn't show up in your dependency lists again. Even some of the Microsoft.* namespaces have properly moved into the BCL SDKs and no longer show up in dependency lists, even though Microsoft.* namespaces originally meant non-BCL first-party.
  - int_19h 1y ago
    I think first-party Microsoft packages ought to be a separate category that is more like BCL in terms of risk. The main reason why they split them out is so that they can be versioned separately from .NET proper.
johannesrexx 1y ago

vachina 1y ago

Node is the embodiment of move and break things. Probably will not build anything that should last more than a few months on node.

testdelacc1 1y ago

I hate to be the guy saying AI will solve it, but this is a case where AI can help. I think in the next couple of years we’ll see people writing small functions with Claude/codex/whatever instead of pulling in a dependency. We might or might not like the quality of software we see, but it will be more resistant to supply chain attacks.

viraptor 1y ago
I wonder what the actual result will be. LLMs can generate functions quickly, but they're also keen to include packages without asking. I've had to add a "don't add new dependencies unless explicitly asked" to a few project configs.
brigandish 1y ago
An approach I learnt from a talk posted to HN (I forget the talk, not the lesson) is to not depend on the outside project for its code, just lift that code directly in to your project, but to rely on it for the tests, requiring/importing it etc when running your own tests. That protects you from a lot of things (this kind of attack was not mentioned, afaic recall) but doesn’t allow bugs found by the other project to be missed either.
short_sells_poo 1y ago
How is this going to solve the supply chain attack problem at all though? It just obfuscates things even more, because once an LLM gets "infected" with malicious code, it'll become much more difficult to trace where it came from. If anything, blind reliance on LLMs will make this problem much worse.
delaminator 1y ago
For sure. I don't think the software ecosystem has come to terms with how things are going to change. Libraries will be providing raw tools like - Sockets, Regex Engine, Cryptography, Syscalls, specific file format libraries LLMs will be building the next layer. I have build successful running projects now in Erlang, Scheme, Rust - I know the basic syntax of two of those but I couldn't write my deployed software in any of them in the couple of hours of prompting. The scheme it had to do a lot of code from first principles and warned me how laborious it would be - "I don't care, you are doing it." I have tools now I could not have imagined I could build in a reasonable time.

larusso 1y ago

I agree partly. I love cargo and can’t understand why certain things like package namespaces and proof of ownership isn’t added at a minimum. I was mega annoyed when I had to move all our Java packages from jcenter, which was a mega easy setup and forget affair, to maven central. There I suddenly needed to register a group name (namespace mostly reverse domain) and proof that with a DNS entry. Then all packages have to be signed etc. In the end it was for this time way ahead. I know that these measures won’t help for all cases. But the fact that at least on npm it was possible that someone else grabs a package ID after an author pulled its packages is kind of alarming. Dependency confusion attacks are still possible on cargo because the whole - vs _ as delimiter wasn’t settled in the beginning. But I don’t want to go away from package managers or easy to use/sharable packages either.

kibwen 1y ago
> But the fact that at least on npm it was possible that someone else grabs a package ID after an author pulled its packages is kind of alarming. Since your comment starts with commentary on crates.io, I'll note that this has never been possible crates.io. > Dependency confusion attacks are still possible on cargo because the whole - vs _ as delimiter wasn’t settled in the beginning. I don't think this has ever been true. AFAIK crates.io has always prevented registering two different crates whose names differ only in the use of dashes vs underscores. > package namespaces See https://github.com/rust-lang/rust/issues/122349 https://github.com/rust-lang/rust/issues/122349 > proof of ownership See https://github.com/rust-lang/rfcs/pull/3724 https://github.com/rust-lang/rfcs/pull/3724 and https://blog.rust-lang.org/2025/07/11/crates-io-development-update-2025-07/#trusted-publishing https://blog.rust-lang.org/2025/07/11/crates-io-development-...
- larusso 1y ago
  You are right. I remembered it wrong. https://rust-lang.github.io/rfcs/0940-hyphens-considered-harmful.html?utm_source=chatgpt.com https://rust-lang.github.io/rfcs/0940-hyphens-considered-har... Was from 2015 and the other discussions I remember were around default style and that cargo already blocks a crate when normalized name is equal.
- 1y ago

moritonal 1y ago

Not knowing that much about apt, isn't _any_ package system vulnerable, and purely a question of what guards are in place and what rights are software given upon install?

viraptor 1y ago
It's not the packaging tech. Apt will typically mean a Debian-based distro. That means the packages are chosen by the maintainers and updated only during specific time periods and tested before release. Even if the underlying software gets owned and replaced, the distro package is very unlikely to be affected. (Unless someone spent months building trust, like xz) But the basic takeover... no, it usually won't affect any Debian style distro package, due to the release process.
- trollbridge 1y ago
  Given the years (or decades) it takes updates to happen in Debian stable, it’s immune to supply chain attacks. You do get to enjoy vulnerabilities that have been out for years, though.
  - FergusArgyll 1y ago
    Security updates are basically immediate, even on stable flavors
  - alt227 1y ago
    > it’s immune to supply chain attacks Thats a strong statement that I can see aging very badly.

TheFlyingFish 1y ago

I've worried about this for a while with Rust packages. The total size of a "big" Rust project's dependency graph is pretty similar to a lot of JS projects. E.g. Tauri, last I checked, introduces about 600 dependencies just on its own. Like another commenter said, I do think it's partially just because dependency management is so easy in Rust compared to e.g. C or C++, but I also suspect that it has to do with the size of the standard library. Rust and JS are both famous for having minimal standard libraries, and what do you know, they tend to have crazy-deep dependency graphs. On the other hand, Python is famous for being "batteries included", and if you look at Python project dependency graphs, they're much less crazy than JS or Rust. E.g. even a higher-level framework like FastAPI, that itself depends on lower-level frameworks, has only a dozen or so dependencies. A Python app that I maintain for work, which has over 20 top-level dependencies, only expands to ~100 once those 20 are fully resolved. I really think a lot of it comes down to the standard library backstopping the most common things that everybody needs. So maybe it would improve the situation to just expand the standard library a bit? Maybe this would be hiding the problem more than solving it, since all that code would still have to be maintained and would still be vulnerable to getting pwned, but other languages manage somehow.

wongarsu 1y ago
I wouldn't call the Rust stdlib "small". "Limited" I could agree with. On the topics it does cover, Rust's stdlib offers a lot. At least on the same level as Python, at times surpassing it. But because the stdlib isn't versioned it stays away from everything that isn't considered "settled", especially in matters where the best interface isn't clear yet. So no http library, no date handling, no helpers for writing macros, etc. You can absolutely write pretty substantial zero-dependency rust if you stay away from the network and async Whether that's a good tradeoff is an open question. None of the options look really great
- deleted 1y ago
  [deleted]
- galangalalgol 1y ago
  Network without async works fine in std. However, rand, serde, and num_traits always seem to be present. Not sure why clap isn't std at this point.

mschuster91 1y ago

> The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. Ambivalent about Go: they have a semblance of packaging system, but nothing so reckless like allowing third-party tarballs uploaded in the cloud to effectively run code on the dev's machine. The alternative that C/C++/Java end up with is that each and every project brings in their own Util, StringUtil, Helper or whatever class that acts as a "de-facto" standard library. I personally had the misfortune of having to deal with MySQL [1], Commons [2], Spring [3] and indirectly also ATG's [4] variants. One particularly unpleasant project I came across utilized all four of them, on top of the project's own "Utils" class that got copy-and-paste'd from the last project and extended for this project's needs. And of course each of these Utils classes has their own semantics, their own methods, their own edge cases and, for the "organically grown" domestic class that barely had tests, bugs. So it's either a billion "small gear" packages with dependency hell and supply chain issues, or it's an amalgamation of many many different "big gear" libraries that make updating them truly a hell on its own. [1] https://jar-download.com/artifacts/mysql/mysql-connector-java/5.1.30/source-code/com/mysql/jdbc/StringUtils.java https://jar-download.com/artifacts/mysql/mysql-connector-jav... [2] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html https://commons.apache.org/proper/commons-lang/apidocs/org/a... [3] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/util/StringUtils.html https://docs.spring.io/spring-framework/docs/current/javadoc... [4] https://docs.oracle.com/cd/E55783_02/Platform.11-2/apidoc/atg/core/util/StringUtils.html https://docs.oracle.com/cd/E55783_02/Platform.11-2/apidoc/at...

sph 1y ago
That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here. And what is wrong with writing your own util library that fits your use case anyway? In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency. No one sane will add a third-party git submodule, wire it to the main Makefile, just to left-pad a string.
- 1y ago

gnfargbl 1y ago

I'm a huge Go proponent but I don't know if I can see much about Go's module system which would really prevent supply-chain attacks in practice. The Go maintainers point [1] at the strong dependency pinning approach, the sumdb system and the module proxy as mitigations, and yes, those are good. However, I can't see what those features do to defend against an attack vector that we have certainly seen elsewhere: project gets compromised, releases a malicious version, and then everyone picks it up when they next run `go get -u ./...` without doing any further checking. Which I would say is the workflow for a good chunk of actual users. The lack of package install hooks does feel somewhat effective, but what's really to stop an attacker putting their malicious code in `func init() {}`? Compromising a popular and important project in this way would likely be noticed pretty quickly. But compromising something widely-used but boring? I feel like attackers would get away with that for a period of time that could be weeks. This isn't really a criticism of Go so much as an observation that depending on random strangers for code (and code updates) is fundamentally risky. Anyone got any good strategies for enforcing dependency cooldown? [1] https://go.dev/blog/supply-chain https://go.dev/blog/supply-chain

_cenw 1y ago
The Go standard library is a lot more comprehensive and usable than Node, so you need less dependencies to begin with.
devttyeu 1y ago
In Go you know exactly what code you’re building thanks to gosum, and it’s much easier to audit changed code after upgrading - just create vendor dirs before and after updating packages and diff them; send to AI for basic screening if the diff is >100k loc and/or review manually. My projects are massive codebases with 1000s of deps and >200MB stripped binaries of literally just code, and this is perfectly feasible. (And yes I do catch stuff occasionally, tho nothing actively adversarial so far) I don’t believe I can do the same with Rust.
- WD-42 1y ago
  cargo vendor

eptcyka 1y ago

Go is just as bad.

Yasuraka 1y ago
Nope. Know the difference.
- eptcyka 1y ago
  How is Go any worse or better than Rust when it comes to the ease of adding dependencies?
  - Yasuraka 1y ago
    I read your comment as in, comparing to node, my bad. With regards to Rust, crates are packages which may include opaque binaries, e.g. serde_derive, and the stdlib is weak, so imports of thousands of lines of code are basically necessary for otherwise fundamental features like async. It's probably easier to add dependencies in Go, but in the end people/projects don't.

zenmac 1y ago

Just a last month someone was trying to figure the cargo tree on which Rust package got imported implicitly via which package. This will totally happen in rust as well as long as you use some kind of package manager. Go for zero or less decencies.

actionfromafar 1y ago
less?
- beeb 1y ago
  decencies?
- troupo 1y ago
  Make it so others depend on you? :)
- officialchicken 1y ago
  Roll your own standard library - or go without one entirely `#![no_std]`
galangalalgol 1y ago
It already did happen. It propogated via build.rs as well. But as I said elsewhere, ut doesn't help you to forgo dependencies part of rust tooling itself.

dwroberts 1y ago

I think this is right about Rust and Cargo, but I would say that Rust has a major advantage in that it implements frozen + offline mode really well (which if you use, obviously significantly decreases the risks). Any time I ever did the equivalent with NPM/node world it was basically unusable or completely impractical

bhouston 1y ago
Pnpm (a very popular npm replacement) makes completely locked packages easy and natural and ultra fast: https://pnpm.io/cli/install https://pnpm.io/cli/install Benchmarks: https://pnpm.io/benchmarks https://pnpm.io/benchmarks
- 15155 1y ago
  pnpm is so laughably terrible compared to Cargo it's not even comparable in the same breath.
  - bhouston 1y ago
    Why specifically? Your comment isn't very informative. Anyhow, here a Claude.ai comparison: https://claude.ai/share/72d2c34c-2c86-44c4-99ec-2a638f10e3f0 https://claude.ai/share/72d2c34c-2c86-44c4-99ec-2a638f10e3f0
    - 15155 1y ago
      Because it doesn't perform as advertised: wild amounts of inconsistencies in behavior (within and between versions), performance issues (pnpm exec adds 15s to all shebang'd execution time over npm/yarn/bun/etc.), etc. Version-to-version stability has been traditionally bad - it's half-baked software. Claude doesn't know this, of course, because it can only read superficial summaries posted on the internet and has zero real experience actually using this dumpster fire.

Davidbrcz 1y ago

Don't worry about C or C++, we create the vulnerabilities ourselves !

GuB-42 1y ago
I get the joke, but that makes me think. What is worse between writing potentially vulnerable code yourself and having too many dependencies. Finding vulnerabilities and writing exploits is costly, and hackers will most likely target popular libraries over your particular software, much higher impact, and it pays better. Dependencies also tend to do more than you need, increasing the attack surface. So your C code may be worse in theory, but it is a smaller, thus harder to hit target. It is probably an advantage against undiscriminating attacks like bots and a downside against targeted attacks by motivated groups.

trollbridge 1y ago

An open question is why PyPI doesn’t have the same problem.

pxc 1y ago
PyPI is also subject to supply chain attacks. What do you mean?

randomint64 1y ago

Indeed, Rust's supply chains story is an absolute horror, and there are countless articles explaining what should be done instead (e.g. https://kerkour.com/rust-stdx https://kerkour.com/rust-stdx) TL;DR: ditch crates.io and copy Go with decentralized packages based directly on and an extended standard library. Centralized package managers only add a layer of obfuscation that attackers can use to their advantage. On the other hand, C / C++ style dependency management is even worse than Rust's... Both in terms of development velocity and dependencies that never get updated.

Ygg2 1y ago
> countless articles explaining what should be done instead (e.g. https://kerkour.com/rust-stdx https://kerkour.com/rust-stdx) Don't make me tap the sign: https://news.ycombinator.com/item?id=41727085#41727410 https://news.ycombinator.com/item?id=41727085#41727410 > Centralized package managers only add a layer of obfuscation that attackers can use to their advantage. They add a layer of convenience. C/C++ are missing that convenience because they aren't as composable and have a long tail of pre-package manager projects. Java didn't start with packages, but today we have packages. Same with JS, etc.
- eichin 1y ago
  Or from another angle, dpkg/apt is the package manager for C/C++ ...
  - Ygg2 1y ago
    Yeah, but it's not immune to supply chain attacks. Counting on maintainers of dpkg is not that different from counting on maintainers of random crate package.

hyperpape 1y ago

Supply chain attacks are scary because you do everything "right", but the ecosystem still compromises you. But realistically, I think the sum total of compromises via package managers attacks is much smaller than the sum total of compromises caused by people rolling their own libraries in C and C++. It's hard to separate from C/C++'s lack of memory safety, which causes a lot of attacks, but the fact that code reuse is harder is a real source of vulnerabilities. Maybe if you're Firefox/Chromium, and you have a huge team and invest massive efforts to be safe, you're better off with the low-dependency model. But for the median project? Rolling your own is much more dangerous than NPM/Cargo.

newpavlov 1y ago

While I agree that dependency tree size can be sometimes a problem in Rust, I think it often gets overblown. Sure, having hundreds of dependencies in a "simple" project can be scary, but: 1) No one forces you to use dependencies with large number of transitive dependencies. For example, feel free to use `ureq` instead of `reqwest` pulling the async kitchen sink with it. If you see an unnecessary dependency, you could also ask maintainers to potentially remove it. 2) Are you sure that your project is as simple as you think? 3) What matters is not number of dependencies, but number of groups who maintain them. On the last point, if your dependency tree has 20 dependencies maintained by the Rust lang team (such as `serde` or `libc`), your supply chain risks are not multiplied by 20, they stay at one and almost the same as using just `std`.

galangalalgol 1y ago
On your last note, I wish they would get on that signed crate subset. Having the same dependency tree as cargo, clippy, and rustc isn't increasing my risk. Rust has already had a supply chain attack propagating via build.rs some years ago. It was noticed quickly, so staying pinned to the oldest thing that worked and had no cve pop in cargo audit is a decent strategy. The remaining risk is that some more niche dependency you use is and always has been compromised.
assbuttbuttass 1y ago
Is serde maintained by the Rust team? I thought it was basically a one-man show owned by dtolnay

rock_artist 1y ago

Using C++ daily, whenever I do js/ts are some javascript variant, since I don't use it daily, and update becomes a very complex task. frameworks and deps change APIs very frequently. It's also very confusing (and I think those attack vectors benefit exactly from that), since you have a dependency but the dep itself dependent on another dep version. Building basic CapacitorJS / Svelte app as an example, results many deps. It might be a newbie question, but, Is there any solution or workflow where you don't end up with this dependency hell?

smt88 1y ago
There's no solution. The JS world is just nonstop build and dependency hell. Being incredibly strict with TS compiler and linter helps a bit.
threetonesun 1y ago
Don't use a framework? Loading a JS script on a page that says "when a update b" hasn't changed much in about 20 years. Maybe I'm being a bit trite but the world of JavaScript is not some mysterious place separate from all other web programming, you can make bad decisions on either side of the stack. These comments always read like devs suddenly realizing the world of user interactions is more complicated and has more edge cases than they think.

woodruffw 1y ago

It’ll probably happen eventually with Rust, but ecosystem volume and informal packaging processes / a low barrier to entry seem to be significant driver in the npm world. (These are arguably good things in other contexts.)

JD557 1y ago

I have a similar opinion but I think Java's model with maven and friends hits the sweet spot: - Packages are always namespaced, so typosquating is harder - Registries like Sonatype require you to validate your domain - Versions are usually locked by default My professional life has been tied to JVM languages, though, so I might be a bit biased. I get that there are some issues with the model, especially when it comes to eviction, but it has been "good enough" for me. Curious on what other people think about it.

oftenwrong 1y ago
Maven does not support "scripts" as NPM does, such as the pre-install script used for this exploit. With scripts enabled, the mere act of downloading a dependency requires a high degree of trust in it.
- 15155 1y ago
  Downloading a dependency also requires a high degree of trust in whatever transitive dependencies that a trusted dependency decides to pull in.

alextingle 1y ago

Every time I look at a new project, my face falls when it's written in Rust. I simply don't trust a system that pulls in gigabytes of god-knows-what off the cloud, and compiles it on my box. It's a real barrier to entry, for me. When I download a C project, I know that it only depends on my system libraries - which I trust because I trust my distro. Rust seems to expect me to take a leap in the dark, trusting hundreds of packagers and their developers. That might be fine if you're already familiar with the Rust ecosystem, but for someone who just wants to try out a new program - it's intimidating.

cyphar 1y ago
On Debian you can use the local registry for Rust which is backed by packages. Though I will say, even as someone who works at a company that sells Linux distributions (SUSE), while the fact we have an additional review step is nice, I think the actual auditing you get in practice is quite minimal. For instance, quite recently[1] the Debian package for a StarDict plugin was configured automatically upload all text selected in X11 to some Chinese servers if you installed it. This is the kind of thing you'd hope distro maintainers to catch. Though, having build scripts be executed in distribution infrastructure and shipped to everyone mitigates the risk of targeted and "dumb" attacks. C build scripts can attack your system just as easily as Rust or JavaScript ones can (in fact it's probably even easier -- look at how the xz backdoor took advantage of the inscrutability of autoconf). [1]: https://www.openwall.com/lists/oss-security/2025/08/04/1 https://www.openwall.com/lists/oss-security/2025/08/04/1
iknowstuff 1y ago
You don't know that about a C project. And you still don't know what lurks in its 1000th reimplementation of http header parsing.
- alextingle 1y ago
  Well, yes I do know when a C project only depends on my system libraries, because otherwise it won't compile. That's the point. Furthermore, for the purposes of this discussion, it really doesn't matter what code there is in the C project. What's there has been put there by the people who run the project. If they are malicious, then at least I know who they are. With Rust, I'm downloading and compiling code from many, many third parties. I have no idea who they are. The potential for one of them to be malicious is much, much higher.

aa-jv 1y ago

> C/C++ .. a convenient package manager Every time I fire up "cmake" I chant a little spell that protects me from the goblins that live on the other side of FetchContent to promise to the Gods of the Repo that I will, eventually, review everything to make sure I'm not shipping poop nuggets .. just as soon as I get the build done, tested .. and shipped, of course .. but I never, ever do.

agumonkey 1y ago

do they follow the same process ? or is it harder to submit a package and vet it on rust/cargo ?

PunchyHamster 1y ago

Rust (and really, any but JS) ecosystem have a bit more "due dilligence" applied everywhere; I don't doubt someone will try to namesquat but chance of success are far smaller > The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. There was no decision in case of C/C++; it was just not a thing languages had at the time so the language itself (especially C) isn't written in a way to accommodate it nicely > Ambivalent about Go: they have a semblance of packaging system, but nothing so reckless like allowing third-party tarballs uploaded in the cloud to effectively run code on the dev's machine. Any code you download and compile is running code on dev machine; and Go does have tools to do that in compile process too. I do however like the by default namespacing by domain, there is no central repository to compromise, and forks of any defunct libs are easier to manage.

JeremyNT 1y ago
> Rust (and really, any but JS) ecosystem have a bit more "due dilligence" applied everywhere; I don't doubt someone will try to namesquat but chance of success are far smaller I really agree, and I feel like it's a culture difference. Javascript was (and remains) an appealing programming language for tinkerers and hobbyists, people who don't really have a lot of engineering experience. Node and npm rose to prominence as a wild west with lots of new developers unfamiliar with good practices, stuck with a programming environment that had few "batteries included," and at a time when supply chain attacks weren't yet on everybody's minds. The barriers to entry were low and, well, the ecosystem sort of reflected that. You can't wash that legacy away overnight. Rust in contrast attracts a different audience because of the language's own design objectives. Obviously none of this makes it immune, and you can YOLO install random dependencies in any programming language, but I don't think any language is ever going to suffer from this in quite the same way and to the same extent that JS has simply due to when and how the ecosystem evolved. And really, even JS today is not JS of yesteryear. Sure there are lots of bad actors and these bad NPM packages sneak in, but also... how widely are all of them used? The maturation of and standardization on certain "batteries included" frameworks rather than ad hoc piecing stuff together has reduced the liklihood of going astray.

chuckadams 1y ago

> It's not "node" or "Javascript" the problem, it's this convenient packaging model. That and the package runtime runs with all the same privileges and capabilities as the thing you're building, which is pretty insane when you think about it. Why should npm know anything outside of the project root even exists, or be given the full set of environment variables without so much as a deny list, let alone an allow list? Of course if such restrictions are available, why limit them to npm? The real problem is that the security model hasn't moved substantially since 1970. We already have all the tools to make things better, but they're still unportable and cumbersome to use, so hardly anything does.

pas 1y ago
pnpm (maybe yarn too?) requires explicit allowlisting of build scripts, hopefully npm will do the same eventually > security model yep, some kind of seccomp or other kind of permission system for modules would help a lot. (eg. if the 3rd party library is parsing something and its API only requires a Buffer as input and returns some object then it could be marked "pure", if it supports logging then that could be also specified, and so on)
- chuckadams 1y ago
  For all the other things I like about yarn, it still executes build scripts willy-nilly, so I am looking at switching to pnpm. I'm sure my $work is going to love me changing up the build toolchain again... PHP's composer on the other hand requires an allowlist in the project's composer.json. I never would have thought PHP would be the one to be getting stuff like this right. Still, I think the "allow-scripts" section or whatever it's called should be named "allow-unrestricted-access-to-everything". Or maybe just stick "dangerously-" in front, I dunno, and drop it when the mechanism is capable of fine-grained privileges.
- WorldMaker 1y ago
  Deno also requires allowlisting npm scripts. It also has a deeper permissions model in general.

poulpy123 1y ago

> The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. The safest code is the code that is not run. There is no lack of attacks targeting C/C++ code, and odin is just a hobby language for now.

riffraff 1y ago

maybe the solution is what linux & co used for many years: have a team of people who vet and package dependencies.

dijit 1y ago

> but it's only a matter of time until it'll happen on the Rust ecosystem Totally 100% agree, though tools like cargo tree make it more of a tractable problem, and running vendored dependencies is first class at least. The one I am genuinely most concerned of is Golang. The way Dependencies are handled leaves much to be desired, I'm really surprised that there haven't been issues honestly.

kunley 1y ago

Why the word "semblance" with regard to Go modules? Are you trying to say this system is lacking something?

SkiFire13 1y ago

Not having a convenient package manager doesn't mean you don't need the functionality that's otherwise offered by third-party packages, it just means that you either need other means to obtain those third-party packages (usually reducing the visibility this dependency!) or implement them yourself (sometimes this is good, but sometimes this can also be very bad for security. Your DYI code won't get as many eyes and audits as the popular third party package!). Must read: https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies

parliament32 1y ago

Agreed, rust's cargo model is basically the worst part of that ecosystem right now. I've had developers submit pretty simple cli tools with hundreds and hundreds of dependencies. I guess there wasn't any lessons learned from the state of NPM.

ratmice 1y ago

My feeling is that languages with other packing models are merely less convenient, and there is no actual tangible difference security-wise. Just take C and replace "look for writable repositories". It just takes more work and is less uniform to say write a worm that looks for writable cmake/autoconf and replicate that way. What would actually stop this is writing compilers and build systems in a way that isolates builds from one another. It's kind of stupid that all a compiler really needs is an input file, a list of dependencies, and an output file. Yet they all make it easy to root around, replicate and exfiltrate. It can be both convenient and not suffer from these style of attacks.

skydhash 1y ago
Not really. cmake and automake are for compiling the library, not for the downloading it. The gap between the two is what's get erased from npm. And it made worse because of the auto update set by default when `npm install` is run.

lijok 1y ago

I don’t get this I installed the package, obviously I intend to run it. How does getting pwned once I run it manually differ from getting pwned once I install it? I’m still getting pwned

skydhash 1y ago
NPM default installation method does not really lock down you dependencies. It allows for update when the patch number (semver) is increased. Which is why those malware bump it up. Anyone who then run `npm install` will get it and will run the code.

kpcyrd 1y ago

Out of the 789 npm packages in this incident, only 4 were ever used in any dependency tree of any Linux operating system (including Homebrew). Not in the affected versions, but ever. If your Rust software observes a big enough chunk of the computer fever dream you are likely to end up with 2-3 digit amount of Rust dependencies, but they are probably all going to be high profile ones (tokio, anyhow, reqwest, the hyper crates, ...), instead of niche ones that never make it into any operating system. This is not a silver bullet of course, but there seems to be an inverse correlation between "is part of any operating system dependency tree" and "gets compromised in an npm-like incident".