5 ms·

The problem is most developers and/or management don't care about security. They only care about being done as fast and/or as cheaply as possible. I'm still no

by sai_c 6y ago

The problem is most developers and/or management don't care about security. They only care about being done as fast and/or as cheaply as possible. I'm still not convinced the new languages (Rust & Zig) will change the overall situation. Why? Simple example in Rust: "LOL! I need to get stuff done." unsafe { Really nasty hacks here to circumvent any obstacles. } Example in Zig: "LOL! I need to get stuff done. Tests? What tests???" zig build-exe example.zig -O ReleaseFast Trying to solve those security bugs with the help of the language is of course the low hanging fruit. But systems languages will always need an escape hatch for certain problems to be solved. And those mechanisms WILL be abused in the name of "get it done already". So we really need other means to erase those bug classes. Which ones I don't know.

rmrfrmrf 6y ago
In an iterative development process, it's not the end of the world to get potentially unsafe code out the door and then make it safe later, and there's a huge benefit in having unsafe code labeled and framed in source when security bugs are found.
pron 6y ago
We haven't yet solved the problem of how to most effectively reduce such issues in projects where developers and management do care about security (and there are certainly more now that companies can be heavily fined for data breaches), so let's tackle that one first.
neysofu 6y ago
> Trying to solve those security bugs with the help of the language is of course the low hanging fruit. I'm not sure I follow, it seems to me like it's actually a freaking high-hanging fruit. The amount of engineering and design that goes into creating a safe, fast, low-level programming language (i.e. Rust in this case) is enormous and it requires huge amounts of upfront investment. The only reason the industry has largely resorted to unsafe languages is because there's many other lower-hanging fruits, e.g. fuzzing, rigorous unit testing, static analysis tools. These help immensely but at the end of the day only take you so far.
skocznymroczny 6y ago
Yes, most developers and management don't care about security, that's why it's important to bake the security into the language. Unsafe blocks are inconvenient and stand out, so their usage will be limited, while the remaining code will be safe. 90% safe code and 10% unsafe code is much safer than 100% unsafe code.
- yabudemada 6y ago
  Honestly, just let them have a buffer-overflow. That's what we call "junk food" software and if they are negligent, let them fail.
stjohnswarts 6y ago
This is a problem you can't fix 100%, it has to be taught through catastrophic failure unfortunately. It's a human flaw, rust (et. al.) gives a pathway forward after that.
ymbeld 6y ago
This comment is as low-effort as the hypothetical examples. Will they do things in that way? Heck, let’s just ask: are they doing things in those ways? crickets Just meaningless rhetoric (“being done fast and/or cheaply”) and unfounded hypotheticals.
anewhnaccount2 6y ago
If you just need to get stuff done in Rust you can just start wrapping things in Rc<>, Arc<>, Box<> or even Gc<>, which introduces runtime overhead on the level of Java. It's safe and allows you to work around thinking about ownership which I think is the main pain-point of using Rust versus other languages. Obviously later if it performance becomes critical you can refactor.

by sai_c 6y ago

rmrfrmrf 6y ago

In an iterative development process, it's not the end of the world to get potentially unsafe code out the door and then make it safe later, and there's a huge benefit in having unsafe code labeled and framed in source when security bugs are found.

pron 6y ago

We haven't yet solved the problem of how to most effectively reduce such issues in projects where developers and management do care about security (and there are certainly more now that companies can be heavily fined for data breaches), so let's tackle that one first.

neysofu 6y ago

> Trying to solve those security bugs with the help of the language is of course the low hanging fruit. I'm not sure I follow, it seems to me like it's actually a freaking high-hanging fruit. The amount of engineering and design that goes into creating a safe, fast, low-level programming language (i.e. Rust in this case) is enormous and it requires huge amounts of upfront investment. The only reason the industry has largely resorted to unsafe languages is because there's many other lower-hanging fruits, e.g. fuzzing, rigorous unit testing, static analysis tools. These help immensely but at the end of the day only take you so far.

skocznymroczny 6y ago

Yes, most developers and management don't care about security, that's why it's important to bake the security into the language. Unsafe blocks are inconvenient and stand out, so their usage will be limited, while the remaining code will be safe. 90% safe code and 10% unsafe code is much safer than 100% unsafe code.

yabudemada 6y ago
Honestly, just let them have a buffer-overflow. That's what we call "junk food" software and if they are negligent, let them fail.

stjohnswarts 6y ago

This is a problem you can't fix 100%, it has to be taught through catastrophic failure unfortunately. It's a human flaw, rust (et. al.) gives a pathway forward after that.

ymbeld 6y ago

This comment is as low-effort as the hypothetical examples. Will they do things in that way? Heck, let’s just ask: are they doing things in those ways? crickets Just meaningless rhetoric (“being done fast and/or cheaply”) and unfounded hypotheticals.

anewhnaccount2 6y ago

If you just need to get stuff done in Rust you can just start wrapping things in Rc<>, Arc<>, Box<> or even Gc<>, which introduces runtime overhead on the level of Java. It's safe and allows you to work around thinking about ownership which I think is the main pain-point of using Rust versus other languages. Obviously later if it performance becomes critical you can refactor.