This shouldn't have happened: A vulnerability postmortem

As a crude example, there sometimes are off-by-one bugs which allow the buffer to overflow by one byte, and that single overflowing byte is always 0 (the last bye in a zero-terminated string), and it overwrites data in a variable that doesn't affect anything meaningful, giving you a buffer overflow with no security impact.

> everything is just pulled from github

I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem?

> you only have to make sure you've got gigabytes of free space in ~/.cache/

I cleared my $GOCACHE relatively recently (I thought maybe I had a cache issue, but I was mistaken), but it's currently at 75M while my .cargo directory weighs 704M. If these ever really got too big I would just `go clean -cache` and move on with life. If this is one of the biggest issues with Go/Rust/etc then I think you're arguing my point for me.

> a build environment that was released in the past four to nine days

What does this even mean? You can compile Go or Rust programs on any Linux machine with the build tools. On the contrary, C/C++ dependencies are very tightly coupled to the build environment.

> have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system

Not sure about Rust programs, but Go programs absolutely don't run arbitrary code at compile/install time. C programs on the other hand absolutely do run arbitrary code (e.g., CMake scripts, Makefiles, random bash scripts, etc).

> I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something.

Yeah, Python package management is a trashfire; however, this is entirely because it is so tightly coupled to C dependencies (many Python libraries are thin wrappers around various C programs, each with their own bespoke build system). Python package management tries to paper over the universe of C packages and it kind of works as long as you're on a handful of well-supported distributions and your dependencies have been well-vetted and well-maintained.

Counterexample: msgrcv(). This expects you to not be passing raw buffers, but messages with a particular structure: a long mtype, to specify what type of message it is, and then a char (byte, since this is C) array that is the buffer that contains the rest of the message. You pass these structures to msgsnd() and msgrcv(), along with a size. But the size is the size of the buffer component of the structure, not the size of the structure as a whole. If you pass the size of the structure, it will read sizeof(long) more than your structure can hold. Been bit by that...

So, just passing the size of the destination is something that you can still get wrong, in the case of data more complicated than just a single buffer.

[Edit: You can also design an API to be very misleading, even if it has a length parameter...]

I don't understand your argument.

In 1982 C was a decade old and still very niche.

In 1992 C++ was a decade old and still very niche.

In 2002 Python were both about a decade old and very niche.

In 2005 Javascript was a decade old and still very niche (only used on some webpages, the web was usable without javascript for the most part).

I think it's safe to say that all of them went on to enjoy quite a bit of success/widespread use.

Some languages take off really fast and go strong for a long time (php and java come to mind).

Some languages take off really fast and disappear just as fast (scala, clojure).

Some languages get big and have a long tail, fading into obscurity (tcl, perl).

Some languages go through cycles of ascendancy and descendancy (FP languages come to mind for that).

Dismissing a language because of it's adoption rate seems kinda silly - no one says "don't use python because it wasn't really popular til it had existed for over a decade".