"No way to prevent this" say users of only language where this regularly happens
xeiaso.netFor anyone who doesn't regularly follow The Onion, the verbiage in this post is directly copied from the story The Onion posts after every major mass-shooting in the United States.
An example: https://www.theonion.com/no-way-to-prevent-this-says-only-na...
I knew I recognized it from somewhere, thanks for the context
Very funny!
I just did some coding on C for the first time in years. Now, ok, i'm out of practice, but I'm generally a fairly cautious programmer. I got so many seg faults and weird memory errors in my code. Valgrind found some more that I hadn't spotted.
It's just too easy to screw it up. Much better to use languages that remove entire classes of bug without you having to even think about it.
Related (as linked in the article):
CVE-2023-6246: Heap-based buffer overflow in the glibc's syslog()
I'm almost positive the project being dunked on here is older than the author. There are plenty of reasons to hate glibc, but nothing productive comes of this kind of noise. It's not like heap overflows are impossible in other languages. Consult https://github.com/rust-lang/rust/issues/80894 or consult your preferred CVE database.
Would love to know what language the author thinks glibc should have been written in in the late eighties.
I think the dunk is funny, and at the same time recognize that glibc is invaluable. At least here the attackers had to do some memory tricks - in other (apparently safer) languages they just get arbitrary code execution directly implemented in the logger!
Good point, since of course we’re all using the version of glibc written in the late eighties. (???)
Where in the intervening time would you have recommended a rewrite? Into which language? The other successful libc projects for linux -- bionic and musl -- are also written in C. Which language should they have been written in? Why do you suppose they weren't?
There may be other reasons it’s the way it is, I’m just saying the language choice made 40 years ago is not one of the valid reasons. People do rewrite things, even complicated things, in different languages all the time when there’s sufficient benefit. There have been plenty of other major changes to glibc in that time.
So they should rewrite an implementation of the C standard library in not-C?
It’s a component with very, very high leverage. If you improve glibc then you’ve improved millions of other programs. So I would think all options are on the table.
> users of the only programming language in the world where these vulnerabilities regularly happen once or twice per quarter for the last eight years
I wish!
Rewrite in Rust?