We are currently in a thread, where a major application has a heap corruption error in its CSS parser, and it's not even rare for such errors to occur. This doesn't seem true.
>But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for.
Last year there was a backdoor inserted into xz that was only caught because someone thought their CPU usage a little too high. I don't think the whole "C is safer because people don't use dependencies" is actually sound.
The last 40-50 years have conclusively shown us that relying on the programmer to be disciplined, yourself included, does not work.
It's 'just a compiler' (ok, a bit more than that). I don't need to use a particular IDE, a particular build system, a particular package manager or even a particular repository.
That is not to throw shade on those other languages, each to their own, but I just like my tools to stay in their lane.
Just like I have a drawer full of different hammers rather than one hammer with 12 different heads, a screwdriver, a hardware store and a drill attachment. I wouldn't know what to do with it.
https://github.com/casey/just/blob/master/Cargo.toml
That’s just asking for trouble down the line.
They’ll stick with a stable version that has the features they need until they have a good reason to move. That version will be one they’ve decided to ship themselves, or it’ll be provided by someone like Debian or Red Hat.
That being said as many above have pointed out you can choose not to bring in dependencies. The Chrome team already does this with the font parser library they limit dependencies to 1 or 2 trusted ones with little to no transitive dependencies. Let's not pretend C / C++ is immune to this we had the xz vuln not too long ago. C / C++ has the benefit of the culture not using as many dependencies but this is still a problem that exists. With the increase of code in the world due to ai this is a problem we're going to need to fix sooner rather than later.
I don't think the supply chain should be a blocker for using rust especially when once of the best C++ teams in the world with good funding struggles to always write perfect code. The chrome team has shown precedent for moving to rust safely and avoiding dependency hell, they'll just need to do it again.
They have hundreds of engineers many of which are very gifted, hell they can write their own dependencies!
The problem exists in C/C++ too, but the depth of dependencies are much smaller though, making the attack surface smaller, and damage gets spread to fewer products.
If I personally had to choose between a product written in C without dependencies to run on openbsd versus the same product written in rust with a few dependencies I would probably choose the C implementation. Even if there is a memory bug, if the underlying system is right they are extremely difficult/expensive to exploit. Abusing a supply chain on the other hand is very easy
It's a culture problem and I still have hope we can change that. My big hope is that as more big players get into it, windows, linux, android, chome, we'll get high quality stand alone packages. Many of these products have to reach certain standards. We saw this recently with JPEGXL. It got accepted into chromium and they've been diligent as to not bring in additional external dependencies.
Projects like sudo-rs take the same approach. As always good engineers will make good code as more of a niche for rust gets carved out I belive we'll see an ecosystem more like c / cpp and less like nodejs (of course this is just my sepeculation)
Memory safety related security exploits happen in a steady stream in basically all non-trivial C projects, but supply chain attacks, while possible, are much more rare.
I'm not saying we shouldn't care about both issues, but the idea is to fix the low hanging fruit and common cases before optimizing for things that aren't in practice that big of a deal.
Also, C is not inherently invulnerable to supply chain attacks either!
If anything, what are you doing about supply chain for the existing code base? How is cargo worse here when cargo-vet exists and is actively maintained by Google, Mozilla, and others?
