4 ms·

> If anything, tools to help write C, or find errors, test, etc... are the more likely path. Ugh, as if we haven't been going down this path for three decades.

> If anything, tools to help write C, or find errors, test, etc... are the more likely path. Ugh, as if we haven't been going down this path for three decades. We're still getting shit like heartbleed. When can we admit that path doesn't work and start trying other things?

xamuel 11y ago
Heartbleed is a symptom of bad programming, not a bad language. C is "less secure" because it allows the programmer to do possibly-unsafe things at their own discretion. The alternative is to flat-out ban those things. Which is appropriate for some use cases (the kind where performance doesn't matter). Inappropriate for others (the kind where performance does matter).
- zacharycohn 11y ago
  This is what designers think about all the time. How can a tool be designed so the unknowing user can't accidentally do something bad? Heartbleed didn't happen on purpose, it was an accident. If you place all of the responsibility on the developer to catch, and be aware of, all possible weaknesses and attack vectors... Well you get today, that's what.
- copsarebastards 11y ago
  > Heartbleed is a symptom of bad programming, not a bad language. Okay, so your claim is tantamount to "every major C program is badly programmed", because every major C program has memory related bugs. If it's really bad programming, not a bad language, why is it that C is so much more often poorly programmed than, say, Python? If it's C programmers, not the C language, then we should avoid C because that's the easiest way to avoid these terrible C programmers. > C is "less secure" because it allows the programmer to do possibly-unsafe things at their own discretion. The alternative is to flat-out ban those things. That's not the only alternative, you're just ignorant of the alternatives.
  - xamuel 11y ago
    >why is it that C is so much more often poorly programmed than, say, Python? It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. >That's not the only alternative Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine).
    - copsarebastards 11y ago
      > It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. You can make any argument by analogy. > Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Suppose we don't suppose things that are wrong. Static type checking can check bounds at no runtime cost this in many cases. Like I said, your argument is based on ignorance of the alternatives. > Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine). I'm not hoping for 100% formal verification here, I'm merely hoping to be significantly better than C. That's a very low bar: C does very little checking. Why on earth would you be opposed to this? In fact, I don't think we'll ever be able to 100% formally verify that a program does what it's supposed to. You can verify some things, like memory access, but in the end we'll never be able to 100% verify that the thing we are verifying is the desired behavior. Look, I'm not criticizing the people who made C or the people who wrote tons of code in C. C was a great language in its time. But it's literally 4 decades old: it would be unreasonable to expect it to not show signs of age.
ddingus 11y ago
Trying other things is good. Interoperating with C is good. But the reality is we've got a huge code body with a ton of use and reuse value out there. Can't just walk away from that. And we've got the lower level, close to the metal use cases these higher level things we like depend on too. Can't really walk from those. Heck, Assembly Language still plays a part in drivers and other low level / boot strapping type activities needed to bring new tech online.
- copsarebastards 11y ago
  We've got major projects rewriting both OpenSSH and libgpg. Both in C. Nobody is saying it's easy to rewrite all of this code, but that is all the more reason to do it right, since we're doing it anyway.
Sanddancer 11y ago
Shit like heartbleed happens because OpenSSL was actively subverting system level libraries like malloc because it was too "slow". What we need are people willing to do the dirty work and audit libraries for practices that are horrible. Additionally, we need to make -Wall -Werror the default flags for C compilers, to make sure people are writing reasonable code. Furthermore, we need to convince C programmers that things like compile as you type are rather useful, and that they should stop clinging to toolchains that don't support it. In a sane world, the compiler would be a library like everything else, so ambiguous code can be handled much sooner in the process.
- copsarebastards 11y ago
  There are some things that none of these tools you mention will fix. As long as we're committed to C design flaws introduced decades ago there are some types of checks we simply won't be able to add. If we're going to all the effort of learning a gigantic tool chain, why not learn a simpler language that gives us more checking than the tool chain does anyway?

xamuel 11y ago

Heartbleed is a symptom of bad programming, not a bad language. C is "less secure" because it allows the programmer to do possibly-unsafe things at their own discretion. The alternative is to flat-out ban those things. Which is appropriate for some use cases (the kind where performance doesn't matter). Inappropriate for others (the kind where performance does matter).

zacharycohn 11y ago
This is what designers think about all the time. How can a tool be designed so the unknowing user can't accidentally do something bad? Heartbleed didn't happen on purpose, it was an accident. If you place all of the responsibility on the developer to catch, and be aware of, all possible weaknesses and attack vectors... Well you get today, that's what.
copsarebastards 11y ago
> Heartbleed is a symptom of bad programming, not a bad language. Okay, so your claim is tantamount to "every major C program is badly programmed", because every major C program has memory related bugs. If it's really bad programming, not a bad language, why is it that C is so much more often poorly programmed than, say, Python? If it's C programmers, not the C language, then we should avoid C because that's the easiest way to avoid these terrible C programmers. > C is "less secure" because it allows the programmer to do possibly-unsafe things at their own discretion. The alternative is to flat-out ban those things. That's not the only alternative, you're just ignorant of the alternatives.
- xamuel 11y ago
  >why is it that C is so much more often poorly programmed than, say, Python? It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. >That's not the only alternative Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine).
  - copsarebastards 11y ago
    > It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. You can make any argument by analogy. > Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Suppose we don't suppose things that are wrong. Static type checking can check bounds at no runtime cost this in many cases. Like I said, your argument is based on ignorance of the alternatives. > Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine). I'm not hoping for 100% formal verification here, I'm merely hoping to be significantly better than C. That's a very low bar: C does very little checking. Why on earth would you be opposed to this? In fact, I don't think we'll ever be able to 100% formally verify that a program does what it's supposed to. You can verify some things, like memory access, but in the end we'll never be able to 100% verify that the thing we are verifying is the desired behavior. Look, I'm not criticizing the people who made C or the people who wrote tons of code in C. C was a great language in its time. But it's literally 4 decades old: it would be unreasonable to expect it to not show signs of age.

ddingus 11y ago

Trying other things is good. Interoperating with C is good. But the reality is we've got a huge code body with a ton of use and reuse value out there. Can't just walk away from that. And we've got the lower level, close to the metal use cases these higher level things we like depend on too. Can't really walk from those. Heck, Assembly Language still plays a part in drivers and other low level / boot strapping type activities needed to bring new tech online.

copsarebastards 11y ago
We've got major projects rewriting both OpenSSH and libgpg. Both in C. Nobody is saying it's easy to rewrite all of this code, but that is all the more reason to do it right, since we're doing it anyway.

Sanddancer 11y ago

Shit like heartbleed happens because OpenSSL was actively subverting system level libraries like malloc because it was too "slow". What we need are people willing to do the dirty work and audit libraries for practices that are horrible. Additionally, we need to make -Wall -Werror the default flags for C compilers, to make sure people are writing reasonable code. Furthermore, we need to convince C programmers that things like compile as you type are rather useful, and that they should stop clinging to toolchains that don't support it. In a sane world, the compiler would be a library like everything else, so ambiguous code can be handled much sooner in the process.

copsarebastards 11y ago
There are some things that none of these tools you mention will fix. As long as we're committed to C design flaws introduced decades ago there are some types of checks we simply won't be able to add. If we're going to all the effort of learning a gigantic tool chain, why not learn a simpler language that gives us more checking than the tool chain does anyway?