Maybe I'm writing it in C because I like the language, enjoy using it and am good with it? And I know it works everywhere I want it, even years later? I hate to be told what I should or shouldn't use.
Then you shouldn't like BCHS or pledge because the author likewise tells you that you should use it and not other things. Regardless of that, this page is all about making the web apps secure. The BCHS page talks something similar. Then, within all this, they recommend a language that goes out of its way to make apps insecure when alternatives exist that don't. Big communities behind some these days.
Recommending against C for web apps is wise in this context.
> Then you shouldn't like BCHS or pledge because the author likewise tells you that you should use it and not other things.
What a non sequitur. That I do not like being told what to (not) use has no bearing whatsoever on whether I can like or dislike the thing that someone somewhere is advocating for or against.
That was partly my point. You bring up you don't like being told what you should or shouldn't use. Yet, you use a product doing exactly that of your own free will. You probably started to after someone shared a link to affect your decision-making. So, a pointless counter in reply to up-thread recommendations.
Do we speak a different language? Because again I just do not understand how any of what you're saying follows.
Yes, I use C. Is the programming language telling me to use this or that? No, I am telling it to do this or that.
And no, I am not using it because somebody told me to. I am using it because (as I said above), I like it, I enjoy using it, I am good with it, and feel like it's a good fit for the values I hold. Opinions shared by other people may have affected my perception, but I am not using the language because somebody tells me to.
Ok. Let's assume all that in light of your previous reply. Do you like your web apps to be secure? Or do you value the personal fulfillment of using C over that? A choice between those two is likely at the bottom of this. "Avoid C if security is priority" still stands with you making a different choice for different priorities.
Yes, I like web apps to be secure, and I believe I can deliver it. Especially when I use C.
But if it really were the case that it is literally impossible to write secure code in C (you'd have to prove it), then my web application should be the least of anyone's worries. Because they are using millions of lines of kernel and library code written in C or C++ to access my web application, which again is hosted on millions of lines of kernel, daemon and library code (including all the crypto) written in C or C++.
And the hypothetical alternative language would likely be implemented in C or C++. And it would be translated to assembly or machine code, a horribly unsafe language. If bugs are inevitable, then no language is safe.
>Because they are using millions of lines of kernel and library code written in C or C++ to access my web application, which again is hosted on millions of lines of kernel, daemon and library code (including all the crypto) written in C or C++.
And which were proven to be unsecure time and time again.
>And the hypothetical alternative language would likely be implemented in C or C++.
Isn't rust self hosted now ?
>And it would be translated to assembly or machine code, a horribly unsafe language.
Not on a Lisp Machine ! ;)
But you are right. Not using C only suppress a class of vulnerabilities, not all of them (and not the most trivial to exploit ones). Unless you are prepared to go all the way and do formal verification, model checking, and NASA style development, your application will be unsecure, and it will be hacked. The question is what is (are ?) your plan to recover when it happens ?
Rust has been self-hosted for a long time. But that doesn't really matter anyway, because the language used to write the compiler has no relevance[1] to vulnerabilities in the compiled code. What is more important is the language the runtime is written in, and Rust's runtime is written almost entirely in Rust (offhand the only parts I know of that aren't are compiler-rt and libbacktrace).
[1] Reflections on Trusting Trust isn't relevant here, we're not considering someone trying to attack the compiler.
>I believe I can deliver it. Especially when I use C.
No, you can't. It's been shown constantly. Buffer overflows. UB. Stack overflow. Dangling pointers. Memory leaks. It will happen.
>it is literally impossible to write secure code in C (you'd have to prove it)
Nobody can prove that. But I can show that it's significantly more error prone. Most other languages have some protections against stack overflow or invalid memory access. Not to mention UB.
>my web application should be the least of anyone's worries.
Not true. Of all the parts of the stack, your webapp is likely the least tested, least used, and thus the most likely to have the most serious bugs. Not to mention that, unlike most of the software you describe, your webapp is likely handling direct user input, the most dangerous location for a bug. And let's not even get into what happens if you're storing sensitive user data.
>And the hypothetical alternative language would likely be implemented in C or C++. And it would be translated to assembly or machine code, a horribly unsafe language. If bugs are inevitable, then no language is safe.
Any backend that generates C can generate near-perfect C code. As for runtimes and compilers written in C, they'll have bugs. All programs have bugs. That's why C sucks. But for the most part, you only have to worry about three issues in the compiler: 1) a built-in function has a bug in it, and doesn't work right. This can happen in any language, including C. 2) the runtime has an error in it that allows user input to cause some kind of memory corruption bug, and exploit it. This is bad, but those codebases are heavily scrutinized, and thus are less likely to contain bugs than the hand-rolled versions that you'd write. 3) there was some kind of GC error. This is probably what you're thinking of.
Two men are walking in the woods. They come across a bear, which starts moving towards them to attack. The first man starts tying his shoes, getting ready to run. The second man asks him, "What are you doing? You can't outrun a bear." And the first man says, "I don't need to outrun the bear. I just need to outrun you."
The same is true of the GC. The GC doesn't have to be perfect, it just has to be better than you. And statistically, you suck at what the GC does.
>If bugs are inevitable, then no language is safe.
Of course no language is safe. But some are safer than others.
"Two men are walking in the woods. They come across a bear, which starts moving towards them to attack. The first man starts tying his shoes, getting ready to run. The second man asks him, "What are you doing? You can't outrun a bear." And the first man says, "I don't need to outrun the bear. I just need to outrun you."
The same is true of the GC. The GC doesn't have to be perfect, it just has to be better than you. And statistically, you suck at what the GC does.
Aka how to sail safely Without a Paddle. ;) Like the analogy and use of statistical argument.
Someone with say 10-20 years of experience in a language will write a more secure program then someone just started in any language ... And even if you program in a "safe" language, you still make bugs, and all those bugs passed the compiler/parser, so your language obviously didn't help you there. There are a lot of code written in C in the wild, witch means there are also a lot of bad code.
There are business logic bugs, and there are memory corruption bugs. One of those leads to RCEs a lot more often than the other. One of those is a lot easier for the compiler to prevent than the other.
Yes, but there are ways to prevent most memory corruption bugs, even, if you're using an OS with a non-terrible malloc implementation. The gnu malloc that most people know is a terrible antiquity that should have been replaced decades ago -- mallocs like OpenBSD's make a lot of memory corruption bugs a lot harder to exploit.
Someone who capably sets out to write their web application back-end in C most likely is aware of any security issues. If they exist in the finished product, their presence is going to be due to laziness, not ignorance.
You don't get points for internet pedantry. Especially when it should be obvious that you're choosing to use a definition of "significant" that doesn't match what I was using in my comment.
virtually,
adverb
[ as submodifier ] nearly; almost: the disease destroyed virtually all the vineyards in Orange County | the college became virtually bankrupt.
Not the person you replied to, but I'm actually quite conflicted on this count. I enjoy C, both aesthetically and for its performance, yet I care a lot about security, so I feel obligated to avoid C for anything important. I'm a big fan of Rust, but it's nowhere near replicating what I like about C.
Then maybe you need to do a better job of shielding yourself from other peoples' opinions? It sounds like might be a little too sensitive and temperamental to engage in mutually beneficial discourse. Please remove yourself.
