5 ms·

From a security perspective, C is inadequate. The implication here being that Rust is adequate, I take it? Let us not circle around the issue! You could asser

by Annatar 10y ago

From a security perspective, C is inadequate. The implication here being that Rust is adequate, I take it? Let us not circle around the issue! You could assert the same for assembler, and yet, assembler is the ultimate programming - the last stop: highest performance, maximum control, no safety. When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? I could think of no language more adequate to push the electronics to their limit, and beyond, as Commodore 64 teaches us over and over again, even in 2016. All I want to say is that your argument rings hollow. Yes, C has no safety. If my code has a hole, it will be noone's fault but my own. And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust. And finally, a Zen koan: I was troubleshooting some code today, which I wrote in AWK. Now the code transformed the data exactly as I had coded it, and the code was 100% correct, the transformed data was exactly as expected, yet no output was coming out. Everything which was in the program was 100% correct. The problem wasn't in that which was in the program, but that which was not: there was no clause to output the transformed data. There is enlightment to be had from this tale, specifically about security, and even more specifically about Rust the programming language and its compiler.

naasking 10y ago
> When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? All the time. Virtually no one would recommend writing any serious software in assembler. The only software written in assembler is high performance numerical code and certain hardware-specific kernel device drivers. > If my code has a hole, it will be noone's fault but my own. And who's going to hold you accountable for that hole that just leaked 100,000 credit card numbers? No one, that's who. The institutional bias against safety and the insulation programmers enjoy from the consequences of their code are the only reason attitudes like yours persist, and the trivial security bugs that inevitably follow. > And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust. Rust the language is not ultracomplex. Don't confuse the language with the compiler.
- pekk 10y ago
  If you want individual programmers to be "held accountable" for bugs they write, it seems that you do not consider their employers or managers even to be involved. This is an overly-simplistic understanding of where bugs come from. Your argument depends on the premise that Rust is necessarily better than (say) C. If it turns out that Rust has a bug in it (it's software, it should have bugs, and it's relatively new software as well), then should the programmer who chose it over something else be liable? What if the alternative were an extremely rigid discipline for C programming using a very mature toolchain? I suspect your evidence for Rust being safer isn't worth taking to court. Thought experiment: if an Evil Dictator simply killed programmers for writing software that contained bugs, would it give rise to a race of perfect programmers? Or would it crush the industry and impair the economy? Would you stake your life on Rust being bug-free? But you can financially ruin almost any engineer for life with the value of a suit for 100,000 credit card numbers. Under that regime, engineers who assumed all the risk would reasonably expect a much larger share of the profits. Are you starting to understand why programmers are not held individually liable for every bug they write?
  - SpaceManiac 10y ago
    Maybe I read it differently, but it seems to me that GP us more concerned with the institutional bias and the attitude rather than anything relating to legal liability... the programmer is allowed to get away with believing that they are taking responsibility for the security of their code, but never feels any consequences for failure, and thus believes they are doing a good job when they are not.
    - naasking 10y ago
      That's phrasing it better than my original rushed comment, thanks. This insular environment doesn't tend to incentivise responsible choices in software development or in deployment. Perhaps liability is one way to address it, but hardly the only way. "Engineer" here in Canada is a protected term and you must belong to the society of professional engineers (P.eng), which carries various legal responsibilities when signing off on work. Requiring code reviews by a P.eng creates a whole different set of incentives, which would emphasise languages that are more expressive, clearer and easier to audit because the P.eng's time is way more costly than the whining of a software developer that wants to squeak 1% more performance out of his inner loops.
geofft 10y ago
> When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? Get some drinks with OpenSSL (or BoringSSL or LibreSSL) hackers and ask them how they feel about perlasm. > If my code has a hole, it will be noone's fault but my own. If you're a one-person development team, you're not talking about the same scale of development the rest of this thread is about.
nickpsecurity 10y ago
"assembler is the ultimate programming - the last stop: highest performance, maximum control, no safety. " Nah, that's microcoding, synthesis of control/data paths in NISC, or use of FPGA's. Assembly is for people that can't handle doing a custom ASIC on their own. ;) https://en.wikipedia.org/wiki/No_instruction_set_computing https://en.wikipedia.org/wiki/No_instruction_set_computing
- Roboprog 10y ago
  And now some guy's about to poke y'all with a soldering iron (etc)... :-)
MaulingMonkey 10y ago
> The implication here being that Rust is adequate, I take it? I think the implication here being that Rust is an improvement. Perhaps not even Rust is adequate, depending on one's needs, but it is at least a step in the right direction. > Yes, C has no safety. If my code has a hole, it will be noone's fault but my own. And that's the way I like it This is the way you and so many other C programmers "like it". As a result, buffer overflows, use after free bugs, and other completely understood reoccurring bugs continue to plague the CVE database in the form of new RCE vulnerabilities. Maybe you're the promised child, the next Buddha, who will usher in a new age of secure C. > I was troubleshooting some code today Oh, you're a mere mortal like the rest of us. Look, I get it, you don't want to give up the "power" of C for the improved memory safety of something else you don't yet understand. But you could really simplify your argument to: "I don't care much about safety, so C is fine." And, hey, you know, that's actually a legitimate argument. I care about safety. I recognize I am mortal, so I have my code reviewed for mistakes. I recognize my reviewers are mortal, so I apply static analysis, unit tests, fuzz testing, and integration tests to catch the mistakes my reviewers won't. Even these are fallible, so I apply all the latest and greatest mitigation that I can - ASLR, stack cookies, W^X, the works. If there's a hole, it will be the "fault" of me, my coworkers, the authors of the tools we use, and so many more. This is a step in the right direction - towards how just how I like it. Where one mortal may fall, perhaps a team of them shall succeed. And yet it's still not enough.
- Annatar 10y ago
  Look, I get it, you don't want to give up the "power" of C for the improved memory safety of something else you don't yet understand. Not quite: I am vehemently against the idea of trading simplicity of C for ultra complexity of Rust, just so I could get some compile time checking, and I will forever be the enemy of that idea. But you could really simplify your argument to: "I don't care much about safety, so C is fine." I care very much about safety. But I will not trade simplicity for an ultra complex language like Rust, just so the compiler could do some compile time checking. Oh, you're a mere mortal like the rest of us. Buddha was a mere mortal too. However, this programming business is special to me. Computers aren't only my passion. They're my life. Maybe you're the promised child, the next Buddha, who will usher in a new age of secure C. And just like all the 33 buddhas, I too am straining and struggling to become one, even if it takes 100,000 years.

by Annatar 10y ago

naasking 10y ago

> When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? All the time. Virtually no one would recommend writing any serious software in assembler. The only software written in assembler is high performance numerical code and certain hardware-specific kernel device drivers. > If my code has a hole, it will be noone's fault but my own. And who's going to hold you accountable for that hole that just leaked 100,000 credit card numbers? No one, that's who. The institutional bias against safety and the insulation programmers enjoy from the consequences of their code are the only reason attitudes like yours persist, and the trivial security bugs that inevitably follow. > And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust. Rust the language is not ultracomplex. Don't confuse the language with the compiler.

pekk 10y ago
If you want individual programmers to be "held accountable" for bugs they write, it seems that you do not consider their employers or managers even to be involved. This is an overly-simplistic understanding of where bugs come from. Your argument depends on the premise that Rust is necessarily better than (say) C. If it turns out that Rust has a bug in it (it's software, it should have bugs, and it's relatively new software as well), then should the programmer who chose it over something else be liable? What if the alternative were an extremely rigid discipline for C programming using a very mature toolchain? I suspect your evidence for Rust being safer isn't worth taking to court. Thought experiment: if an Evil Dictator simply killed programmers for writing software that contained bugs, would it give rise to a race of perfect programmers? Or would it crush the industry and impair the economy? Would you stake your life on Rust being bug-free? But you can financially ruin almost any engineer for life with the value of a suit for 100,000 credit card numbers. Under that regime, engineers who assumed all the risk would reasonably expect a much larger share of the profits. Are you starting to understand why programmers are not held individually liable for every bug they write?
- SpaceManiac 10y ago
  Maybe I read it differently, but it seems to me that GP us more concerned with the institutional bias and the attitude rather than anything relating to legal liability... the programmer is allowed to get away with believing that they are taking responsibility for the security of their code, but never feels any consequences for failure, and thus believes they are doing a good job when they are not.
  - naasking 10y ago
    That's phrasing it better than my original rushed comment, thanks. This insular environment doesn't tend to incentivise responsible choices in software development or in deployment. Perhaps liability is one way to address it, but hardly the only way. "Engineer" here in Canada is a protected term and you must belong to the society of professional engineers (P.eng), which carries various legal responsibilities when signing off on work. Requiring code reviews by a P.eng creates a whole different set of incentives, which would emphasise languages that are more expressive, clearer and easier to audit because the P.eng's time is way more costly than the whining of a software developer that wants to squeak 1% more performance out of his inner loops.

geofft 10y ago

> When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? Get some drinks with OpenSSL (or BoringSSL or LibreSSL) hackers and ask them how they feel about perlasm. > If my code has a hole, it will be noone's fault but my own. If you're a one-person development team, you're not talking about the same scale of development the rest of this thread is about.

nickpsecurity 10y ago

"assembler is the ultimate programming - the last stop: highest performance, maximum control, no safety. " Nah, that's microcoding, synthesis of control/data paths in NISC, or use of FPGA's. Assembly is for people that can't handle doing a custom ASIC on their own. ;) https://en.wikipedia.org/wiki/No_instruction_set_computing https://en.wikipedia.org/wiki/No_instruction_set_computing

Roboprog 10y ago
And now some guy's about to poke y'all with a soldering iron (etc)... :-)

MaulingMonkey 10y ago

> The implication here being that Rust is adequate, I take it? I think the implication here being that Rust is an improvement. Perhaps not even Rust is adequate, depending on one's needs, but it is at least a step in the right direction. > Yes, C has no safety. If my code has a hole, it will be noone's fault but my own. And that's the way I like it This is the way you and so many other C programmers "like it". As a result, buffer overflows, use after free bugs, and other completely understood reoccurring bugs continue to plague the CVE database in the form of new RCE vulnerabilities. Maybe you're the promised child, the next Buddha, who will usher in a new age of secure C. > I was troubleshooting some code today Oh, you're a mere mortal like the rest of us. Look, I get it, you don't want to give up the "power" of C for the improved memory safety of something else you don't yet understand. But you could really simplify your argument to: "I don't care much about safety, so C is fine." And, hey, you know, that's actually a legitimate argument. I care about safety. I recognize I am mortal, so I have my code reviewed for mistakes. I recognize my reviewers are mortal, so I apply static analysis, unit tests, fuzz testing, and integration tests to catch the mistakes my reviewers won't. Even these are fallible, so I apply all the latest and greatest mitigation that I can - ASLR, stack cookies, W^X, the works. If there's a hole, it will be the "fault" of me, my coworkers, the authors of the tools we use, and so many more. This is a step in the right direction - towards how just how I like it. Where one mortal may fall, perhaps a team of them shall succeed. And yet it's still not enough.

Annatar 10y ago
Look, I get it, you don't want to give up the "power" of C for the improved memory safety of something else you don't yet understand. Not quite: I am vehemently against the idea of trading simplicity of C for ultra complexity of Rust, just so I could get some compile time checking, and I will forever be the enemy of that idea. But you could really simplify your argument to: "I don't care much about safety, so C is fine." I care very much about safety. But I will not trade simplicity for an ultra complex language like Rust, just so the compiler could do some compile time checking. Oh, you're a mere mortal like the rest of us. Buddha was a mere mortal too. However, this programming business is special to me. Computers aren't only my passion. They're my life. Maybe you're the promised child, the next Buddha, who will usher in a new age of secure C. And just like all the 33 buddhas, I too am straining and struggling to become one, even if it takes 100,000 years.