4 ms·

> 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

by clarry 10y ago

> 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.

nickpsecurity 10y ago
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.
- clarry 10y ago
  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.
  - nickpsecurity 10y ago
    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.
    - clarry 10y ago
      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.
      - palunon 10y ago
        >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 ?
        eridius 10y ago
        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.
      - 10y ago

by clarry 10y ago

nickpsecurity 10y ago

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.

clarry 10y ago
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.
- nickpsecurity 10y ago
  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.
  - clarry 10y ago
    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.
    - palunon 10y ago
      >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 ?
      - eridius 10y ago
        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.
    - 10y ago