Unfortunately that comes with the baggage of terrible memory safety. I do agree with the sentiment though, that deps should be taken with more consideration.
Isn't this unrelated to the parent post's thoughts about the benefit's of the C/C++ ecosystem (or lack thereof) for dependency management? I.e., a Rust-like language could still exist with a dependency management system similar to what C/C++ have now -- that isn't predicated on how the language handles memory.
Some people will always prefer C to Rust, might as well learn to live with that fact.
My argument is that you are missing the point: the point is that a larger attack surface enables more exploits regardless of language.
When using a language that has tremendous friction in expanding the attack surface you tend to have a small attack surface as a result.
Theres obviously a crossover point where you'd be safer with a memory safe language and a larger attack surface than with a memory unsafe language and a minuscule attack surface.
No I don't, which exploit are you talking about? The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language. The "most expensive software bug" (not an exploit) caused by turning off the safe overflow handler in the language being used can hardly be considered an indictment of language level safety either. So what exploit are you talking about?
I suppose Stuxnet could also count, where the initial infection depends on the human curiosity of plugging an unknown usb drive into an air gapped system.
Log4j
> The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language.
Heartbleed was nowhere near as costly as Log4j. Last I checked, there was two orders of magnitude difference between the cost of fixing Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed).
> Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed)
How are you counting that? There are definitely embedded systems out there running old versions of OpenSSL that will never be patched. Because there's no standard package management and vendoring dependencies is more common in the C world, it's probably less easy to get a list of vulnerable systems, but that doesn't mean the vulnerability isn't there.
Maybe you won't in general, but we're chatting on a thread about the threats of supply chain attacks.
Reading upthread, some GG...P thread espoused the idea that maybe the trade-off in using a memory-safe language with almost frictionless thirdy-party dependency might not always be worth it compared to a memory-unsafe language with very high friction for third-party dependencies.
In this context, the specific comment I replied to made a frankly asinine comment about how "this wouldn't happen in Rust", to which I felt compelled to point out that a) More expensive breaches have occurred in memory safe languages, and b) Supply chain attacks have large dollar impacts anyway.
To add, there's also c) The majority of breaches are occurring irrespective of tech stacks.
A runaway loop can access program memory until it segfaults pretty easily.
What happens before/instead is normally worth a CVE.