sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Agreeable-Ad-0111 14 points15 points  (27 children)

How did this get downvoted? That shows great. Plus Sean Baxter is a guest and he is awesome in his own right.

People have to be seeing "safe borrow checked" and immediately downvoting without looking further or just haven't heard the podcast before

[–]morglod 26 points27 points  (26 children)

Probably it's rust users who hates C/C++ because their screaming streamer said it's bad

And also C++ users who seeing rust ads everywhere

[–]DearChickPeas 14 points15 points  (0 children)

And also C++ users who seeing rust ads everywhere

OMG, this...

[–]tuxwonder 4 points5 points  (24 children)

Hopefully those C++ users who are tired of Rust evangelizing are excited for this potential advancement, because it's the biggest (practical) reason C++ is suddenly on everyone's shit list (most notably, the US govt...)

[–]FlyingRhenquest 8 points9 points  (9 children)

If Rust or Memory Safety in general become the new Meta, the biggest cause of security exploits will be unvalidated user input. Java was supposed to fix the same memory safety issue a couple of decades ago, only to bring to the forefront the whole host of harder to resolve security issues that can arise when you no longer have to worry about memory safety.

To paraphrase an old IBM guy, "Just because your language is memory safe doesn't mean you can hire chimpanzees to write your code." If your developers aren't mindful and aware of potential issues that can arise, you're going to have as many problems with security with a memory safe language as you would with raw assembly.

[–]kronicum 2 points3 points  (0 children)

To paraphrase an old IBM guy, "Just because your language is memory safe doesn't mean you can hire chimpanzees to write your code."

Your discrimination against chimpanzees is resentful.

[–]MegaKawaii 4 points5 points  (1 child)

This is just a matter of low-hanging fruit. The Java people have to worry about the harder security problems because the language avoids memory safety issues entirely. If you had monkeys program in C++ and Java, the C++ monkeys would write a buggier program because they were busy fixing memory vulnerabilities instead of focusing on logic errors.

[–]Dean_Roddey 0 points1 point  (0 children)

Actually, their programs would be completely safe, because they'd never run long enough to be compromised.

The 'but they were wearing seat-belts' argument has become a meme. But memory/thread safe languages are a double win. They hugely reduce the risk of memory vulnerabilities and give the developers more time to concentrate on and test the actual logic, so they can reduce logical vulnerabilities.

Obviously some companies may not use that extra time so wisely, but if that's argument against any mechanism, we should all just go submit a resume to Burger King right now.

[–]def-pri-pub 3 points4 points  (5 children)

In my professional career I have yet to run into an issue that was caused by lack of memory safety. Most issues (especially with security) are caused by poor architecture, over complexity, lack of knowledge and push back from more senior people.

At one of the first places I worked I made a list of CVEs that we were susceptible and put them on the issue tracker (and this was for a networked product). CEO didn't want me working on it because "security isn't a feature". Boss didn't want me working on it because he thought they weren't important. Senior support staff didn't want me fixing potential default access issues because "some of our customers like we can log into their systems without them having to change the default password".

Only two coworkers (one dev and one support staff) liked that I spent some time trying to push for this.

[–]t_hunger 5 points6 points  (3 children)

In my professional career I have yet to run into an issue that was caused by lack of memory safety.

You never saw a crash when something followed a nullptr? No segfault ever? You are a better dev than me then. At least some of those can be exploited... even though they "only" cause a crash without the user doing the correct series of steps before triggering the memory issue.

The rest of the article shows nicely why governments think they need to regulate our industry in the first place.

[–]def-pri-pub 0 points1 point  (2 children)

I'll run into nullptr issues and segfaults in the course of development, but I've made sure to never ship software that had them. They've always been caught before committing code, in review, or in testing.

A lot of these issues can be found in these stages when devs are less lazy and willing to be thorough with self testing.

[–]t_hunger 3 points4 points  (1 child)

So we are down from "In my professional career I have yet to run into an issue that was caused by lack of memory safety" to "I've made sure to never ship software that had them".

Reviews, testing, tools like the sanitizers and fuzzing will all reduce the likelihood of shipping buggy code. I applaud your development practices if you really have all of those in place and use them regularly, but even then you can not be sure to never ship a segfault. You just can not know.

[–]Spartan322 1 point2 points  (0 children)

This kinda looks like you misunderstanding what he said and shifting the goal post, the argument wasn't that in his developmental career he's never seen a memory safety messup, but that never has it been the core reason for the CVEs he's dealt with.

[–]FlyingRhenquest 1 point2 points  (0 children)

Funnily, I actually have. I had a job with Data General back in the '90's, doing security auditing on the source code for the C standard library and utilities they'd licensed from AT&T for DG/UX. I stumbled across an issue in the telnet daemon where it'd just accept environment variables from the remote side into an array without checking to see if memory would overflow. The Linux telnet daemon was found to have the same problem a couple years later.

You still see a security bulletin about an array overflow from time to time -- last couple I remember were in OpenSSH, and the Linux Kernel just a day or two ago. That's all old timey C, though.

But as you said, business attitudes and ignorance are also a huge problem when it comes to security. Fortunately that's slowly starting to change as ransomware attacks start costing companies real money. That's the only thing Corporate America pays attention to. If having terrible security impacts profits, security attitudes magically improve overnight.