3 ms·

Guess who is "rolling your crypto" for you. The same guy who is the subject of your "fallacious benchmark". He writes in C. The problem with software is not

Guess who is "rolling your crypto" for you. The same guy who is the subject of your "fallacious benchmark". He writes in C. The problem with software is not the languages (seems a new one is created every month), it is a lack of competence in using them. (Over)Confidence is very commmon, competence not so much. I am thankful that Dennis Ritchie created C; I appreciated his humility and I do not blame him for others' mistakes.

PeterisP 5y ago
It's not a lack of competence because evidence shows that even the most competent C programmers can't write C without security issues - literally every nontrivial security-relevant product that has been written by great C programmers has had them, their competence apparently was not sufficient. I'd argue that nobody, including Dennis Ritchie, is "competent enough" to write secure C - even the best people slip sometimes in ways that (in C!) cause exploitable holes. "The same guy who is the subject of your fallacious benchmark. He writes in C" and that crypto code, which we used was more secure than rolling our own, but it still is riddled with security bugs because he writes in C (e.g. Heartbleed) - and despite the fact that those particular bugs have been fixed, that code still isn't trustworthy enough just because it's written in C, likely has more issues undetected and needs to be rewritten and replaced eventually with some not-C solution that can remove a whole class of bugs accidentally causing arbitrary code execution. Sure, you'll still have logic bugs - but a logic bug in iMessage image parsing has much lower consequences than a memory safety issue in that same image parsing.
- o8r3oFTZPE 5y ago
  I think you are misattributing the source of Heartbleed. Can you point out the security issues in NaCl. It is written in C. According to this "no one can write C" logic, there must be bugs because "no one can write C". https://nacl.cace-project.eu/ https://nacl.cace-project.eu/ The other bizarre aspect of this logic is that not only is the author of the code irrelevant but apparently the task is, too. It would appear to apply to, e.g., even the most simple programs. The only factor that matters is "written in C". I use sed every day. It's written in C. Show me the bugs. I will probably be dead before someone finds them. Will I be using a "memory-safe" sed before then.
  - staticassertion 5y ago
    Saying "show me the vulns in this codebase" over and over is not a good argument.
    - o8r3oFTZPE 5y ago
      Whereas saying "no one can write C without bugs" over and over is a good argument. Its hyperbole. If the argument was "few people can write C without bugs" that would be much easier to digest.
      - staticassertion 5y ago
        OK, but I didn't say that no one can write C without bugs. I said that blaming languages is good, that we'll all lose due to people continuing to use C, that C programs aren't inherently smaller and faster than other languages, and that people should treat writing C as they would treat writing crypto.
        o8r3oFTZPE 5y ago
        To clarify, I know you may not have said "no one can" but plenty of other HN commenters are saying exactly that on a regular basis. Thank you for refraining from repeating this absurd hyperbole. C programs are not inherently smaller and faster but in practice this is usually the case. Can you guide me to some Rust programs that are smaller than their C counterparts. The thing that holds me back from experimenting more with Rust is the (apparently) enormous size of the development environment relative to a GCC toolchain. The number of downlaods from crates.io is questionably large and some of the binaries I have produced were absolutely gigantic. Largest executables I have ever compiled. Crazy. We do not "lose" if people keep writing in C as long as its the right people. The right programmer for the job. All programmers are not created equal no matter what languages they use. Absent professional certifications and enforceable quality standards, perhaps the world of writing software for use by others needs an ethos something along the lines of "code within your means". Memory-safe languages are great but it seems like they just enable people to become far too ambitious in what they think they can take on. This is no problem at all unless and until they start marketing their grand creation to undiscerning users who are none the wiser. (This is of course the general idea behind the "dont roll your own" meme. However, I do not think it should be limited to cryptography.)

PeterisP 5y ago

It's not a lack of competence because evidence shows that even the most competent C programmers can't write C without security issues - literally every nontrivial security-relevant product that has been written by great C programmers has had them, their competence apparently was not sufficient. I'd argue that nobody, including Dennis Ritchie, is "competent enough" to write secure C - even the best people slip sometimes in ways that (in C!) cause exploitable holes. "The same guy who is the subject of your fallacious benchmark. He writes in C" and that crypto code, which we used was more secure than rolling our own, but it still is riddled with security bugs because he writes in C (e.g. Heartbleed) - and despite the fact that those particular bugs have been fixed, that code still isn't trustworthy enough just because it's written in C, likely has more issues undetected and needs to be rewritten and replaced eventually with some not-C solution that can remove a whole class of bugs accidentally causing arbitrary code execution. Sure, you'll still have logic bugs - but a logic bug in iMessage image parsing has much lower consequences than a memory safety issue in that same image parsing.

o8r3oFTZPE 5y ago
I think you are misattributing the source of Heartbleed. Can you point out the security issues in NaCl. It is written in C. According to this "no one can write C" logic, there must be bugs because "no one can write C". https://nacl.cace-project.eu/ https://nacl.cace-project.eu/ The other bizarre aspect of this logic is that not only is the author of the code irrelevant but apparently the task is, too. It would appear to apply to, e.g., even the most simple programs. The only factor that matters is "written in C". I use sed every day. It's written in C. Show me the bugs. I will probably be dead before someone finds them. Will I be using a "memory-safe" sed before then.
- staticassertion 5y ago
  Saying "show me the vulns in this codebase" over and over is not a good argument.
  - o8r3oFTZPE 5y ago
    Whereas saying "no one can write C without bugs" over and over is a good argument. Its hyperbole. If the argument was "few people can write C without bugs" that would be much easier to digest.
    - staticassertion 5y ago
      OK, but I didn't say that no one can write C without bugs. I said that blaming languages is good, that we'll all lose due to people continuing to use C, that C programs aren't inherently smaller and faster than other languages, and that people should treat writing C as they would treat writing crypto.
      - o8r3oFTZPE 5y ago
        To clarify, I know you may not have said "no one can" but plenty of other HN commenters are saying exactly that on a regular basis. Thank you for refraining from repeating this absurd hyperbole. C programs are not inherently smaller and faster but in practice this is usually the case. Can you guide me to some Rust programs that are smaller than their C counterparts. The thing that holds me back from experimenting more with Rust is the (apparently) enormous size of the development environment relative to a GCC toolchain. The number of downlaods from crates.io is questionably large and some of the binaries I have produced were absolutely gigantic. Largest executables I have ever compiled. Crazy. We do not "lose" if people keep writing in C as long as its the right people. The right programmer for the job. All programmers are not created equal no matter what languages they use. Absent professional certifications and enforceable quality standards, perhaps the world of writing software for use by others needs an ethos something along the lines of "code within your means". Memory-safe languages are great but it seems like they just enable people to become far too ambitious in what they think they can take on. This is no problem at all unless and until they start marketing their grand creation to undiscerning users who are none the wiser. (This is of course the general idea behind the "dont roll your own" meme. However, I do not think it should be limited to cryptography.)