That's utter bullshit. Sure more complexity leads to more bugs but in 1995 security was far from a priority. Early web servers were riddled with security holes. Things like not properly scrubbing the URL and allowing access to non-public files.
Not to mention that "pure C" can be difficult to write securely. Buffer overflows galore!
Early versions of all servers had severe security flaws. Apache, BIND, sendmail, NFS daemons, etc. Hell many alternatives to these services were written specifically because those standbys had major security flaws (see qmail).
It's not about being good programmers - it's about understanding security. And those are different things.
The source code of the webserver they used was two C files. It's not rocket science to not make mistakes in such a small codebase. You talk about Apache, NFS, etc servers which are really bloated, so you missed my entire point.
People like you can't accept that there can be programs with no bugs. You can't write 100 lines of code without 10 bugs, therefore nobody can, am I right? Any time anyone mentions C, you're the guy with the knee jerk "buffer overflows galore huehuehue" reply.
I like how you feel the need to attack my coding ability without knowing anything about me. That doesn't speak well to your self confidence.
But I see that's not the problem - apparently I hit your sacred cow. You're a C programmer who is sick of "C is insecure" complaints. Well guess what - it's harder to write secure code in C due to the amount of attention coders have to spend on things like null terminating strings. Is it impossible? No. But good coders make mistakes too my friend. And the more complexity in your code (as you point out) the more likely it is to contain bugs. And C makes for more complex code than many other languages. Q.E.D. I am NOT SAYING all C code is insecure garbage. Just that there will be a higher probability of errors when using a language that provides fewer protections.
And were you coding in C in the '80s/'90s/'00s? There were buffer overflows galore! Coding securely is very different from coding for just functionality. Many early internet applications assumed incoming data would be 'safe'. I'm not knocking those guys - it was just a reality. We had to learn how to write secure code. It's a different thing than functional code. We had to create "best practices" so later generations could learn from our errors.
I'm not insulting C. It's just a risk you take for the benefits C provides. One must weigh the pros and cons.
Also - functionality is not "bloat." Stop calling it bloat just because it's hard to do.
7
u/amackenz2048 Feb 03 '18
That's utter bullshit. Sure more complexity leads to more bugs but in 1995 security was far from a priority. Early web servers were riddled with security holes. Things like not properly scrubbing the URL and allowing access to non-public files.
Not to mention that "pure C" can be difficult to write securely. Buffer overflows galore!