4 ms·

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 d

by xamuel 12y 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 12y 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 12y 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 12y 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 12y 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.

by xamuel 12y ago

zacharycohn 12y 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 12y 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 12y 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 12y 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.