While the brain cells of the C programmers are busy handling errors, managing memory, and avoiding buffer overflow, they forget about sound software engineering rules and proper design. While the code of libssh looks cleaner than eg. FreeBSD, there are still quite a number of functions that are bigger than a screen height.
I don't see how different language would protect you from this kind of vulnerability. Array of callbacks looks identical everywhere. Rust or Java would protect from out-of-bounds memory access (and that is a very good thing in that case), but this particular bug would be present.
You're assuming there would even be an array of callbacks if the code had been written in a different language, rather than the other language offering some nicer abstraction that eliminated the array. Having not seen the code, I can't be sure of this, but I know that, for instance, I rarely need to write array index arithmetic in the languages I usually work with (Python, JavaScript) whereas on the occasions I've dabbled with C such arithmetic came up constantly. If I introduced a nasty bug in some C code due to an array arithmetic error, arguing "Python wouldn't be any better because it doesn't do anything to make manually writing array index manipulations easier" would be missing the point.
A perfect example of why "use safe languages! C is the root of all RCE!" makes me immediately weary of a developer. Had the original poster been the author of such a library, he wouldn't have been motivated to spent much or any time investigating his implementation because he used a safe language.
Same issue and might even explain it better: They took the client-side implementation and effective state machine, flipped it around, and called it good.
And that's why you should use a thoroughly tested implementation instead of implementing a bug-ridden ad-hoc square wheel.
"Whoopsies, I forgot to ban some state transitions" won't happen if all you're writing is a state machine spec, and not a state machine spec and its ad-hoc implementation.
Don't roll your own crypto? Extend it to "don't roll your own low-level constructs".
> they forget about sound software engineering rules and proper design. While the code of libssh looks cleaner than eg. FreeBSD, there are still quite a number of functions that are bigger than a screen height.
You seem to be a very smart guy; will making my font smaller so my functions are shorter improve my code?
While the brain cells of the C programmers are busy handling errors, managing memory, and avoiding buffer overflow, they forget about sound software engineering rules and proper design. While the code of libssh looks cleaner than eg. FreeBSD, there are still quite a number of functions that are bigger than a screen height.