4 ms·

Yes. Some people (myself included) enjoy "unsafe" languages like C. I'm not one of those people that argue that being careful is enough. For applications where

Yes. Some people (myself included) enjoy "unsafe" languages like C. I'm not one of those people that argue that being careful is enough. For applications where security really matters, _please_ use something with a bit more verification (though even that doesn't disqualify C, see seL4). Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety? I'd argue it's unnecessary, I can't remember a time where I saw a program like this print 'segmentation fault'. I encourage anyone to write new software in "unsafe" languages, so long as it's not a security risk.

quotemstr 4y ago
> Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety Any program that operates on untrusted data can be a security vulnerability. If an attacker can make your text editor execute arbitrary code if you open a specially crafted file, that's a major security problem. Why would you create the risk of this sort of problem on purpose when we have adequate safe languages these days? Instead of making people decide on a case-by-case basis when "security really matters", let's make all programs safe. I mean, isn't your suggestion that text editors have not security implications evidence in itself that people will get it wrong when asked, "Does my program need security?".
- swinglock 4y ago
  Even an offline game is dangerous. What if the save files are backed up and that storage is compromised? This allows an attacker to escalate access from one computer or service to others.
  - unsafecast 4y ago
    These are issues for the operating system to care about, not every single application. With pledge and unveil (or similar), you can solve most of this once.
- unsafecast 4y ago
  Not if the entire editor is untrusted. This is the job of the operating systems, and simple mechanisms like pledge and unveil can solve most of this.
mk89 4y ago
Yet OWASP vulnerabilities hit lots of non-C languages and things that you definitely don't do in C: https://owasp.org/Top10 https://owasp.org/Top10 I am starting to wonder lately if all this "implicit language security" (use Rust, use Go so you don't have memory errors, overflows, etc.) is not just some way to shift accountability to some other layer. I do understand that lower level languages require better programming skills because you actually need to know what you are doing, unlike Python which generally shields you from a lot of ugly things, but that's about it. You can do bad shit in Python/Java too. And that happens like A LOT. So what are we actually protecting our services/software from? Reducing the attack surface, totally agreed. But then log4j... Or are we moving to more "user-friendly" languages because they don't require such an amount of knowledge? I don't know. I do see the value Rust and Go create, but if we follow good software practices in C, don't you think we could ship decent safe software there too? Or are all C programs inherently buggy by default?
- nequo 4y ago
  Safe Rust and Go eliminate one class of bugs, memory errors. They do not eliminate bugs in the business logic. Does this mean that eliminating memory errors is not worth it? I don’t think so. In C you have both memory errors and business logic bugs. So it takes more effort to get C code right than Rust.
- bitwize 4y ago
  > I am starting to wonder lately if all this "implicit language security" (use Rust, use Go so you don't have memory errors, overflows, etc.) is not just some way to shift accountability to some other layer. No, it's a way to eliminate THE MOST COMMON CLASS OF SECURITY BUG. Boom, gone, because you used safe Rust instead of C. It doesn't mean you won't discover other bugs -- you will. But those bugs might have lurked undiscovered because you were too busy fighting buffer overflows and UAFs. Any given team of engineers has only so much time and energy; with fewer bug types to eliminate, the same team can get closer to bug-free. This is why the My Little Pony character alter of your average 25-year-old trans furry plural system wearing uwu kawaii programming socks, working in Rust, can code circles around even the most jaded C grognard with decades of experience -- and will be writing an OS kernel or driver near you. > I don't know. I do see the value Rust and Go create, but if we follow good software practices in C, don't you think we could ship decent safe software there too? Or are all C programs inherently buggy by default? All C programs but the most trivial are inherently buggy by default. As I put it, C is unsafe at any speed. Theoretically, it should be possible to establish sound disciplines and best practices to ensure safe C code, but experience has taught us that C is so full of potholes and footguns that it is practically impossible to write safe C even for experienced developers.

quotemstr 4y ago

> Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety Any program that operates on untrusted data can be a security vulnerability. If an attacker can make your text editor execute arbitrary code if you open a specially crafted file, that's a major security problem. Why would you create the risk of this sort of problem on purpose when we have adequate safe languages these days? Instead of making people decide on a case-by-case basis when "security really matters", let's make all programs safe. I mean, isn't your suggestion that text editors have not security implications evidence in itself that people will get it wrong when asked, "Does my program need security?".

swinglock 4y ago
Even an offline game is dangerous. What if the save files are backed up and that storage is compromised? This allows an attacker to escalate access from one computer or service to others.
- unsafecast 4y ago
  These are issues for the operating system to care about, not every single application. With pledge and unveil (or similar), you can solve most of this once.
unsafecast 4y ago
Not if the entire editor is untrusted. This is the job of the operating systems, and simple mechanisms like pledge and unveil can solve most of this.

mk89 4y ago

Yet OWASP vulnerabilities hit lots of non-C languages and things that you definitely don't do in C: https://owasp.org/Top10 https://owasp.org/Top10 I am starting to wonder lately if all this "implicit language security" (use Rust, use Go so you don't have memory errors, overflows, etc.) is not just some way to shift accountability to some other layer. I do understand that lower level languages require better programming skills because you actually need to know what you are doing, unlike Python which generally shields you from a lot of ugly things, but that's about it. You can do bad shit in Python/Java too. And that happens like A LOT. So what are we actually protecting our services/software from? Reducing the attack surface, totally agreed. But then log4j... Or are we moving to more "user-friendly" languages because they don't require such an amount of knowledge? I don't know. I do see the value Rust and Go create, but if we follow good software practices in C, don't you think we could ship decent safe software there too? Or are all C programs inherently buggy by default?

nequo 4y ago
Safe Rust and Go eliminate one class of bugs, memory errors. They do not eliminate bugs in the business logic. Does this mean that eliminating memory errors is not worth it? I don’t think so. In C you have both memory errors and business logic bugs. So it takes more effort to get C code right than Rust.
bitwize 4y ago
> I am starting to wonder lately if all this "implicit language security" (use Rust, use Go so you don't have memory errors, overflows, etc.) is not just some way to shift accountability to some other layer. No, it's a way to eliminate THE MOST COMMON CLASS OF SECURITY BUG. Boom, gone, because you used safe Rust instead of C. It doesn't mean you won't discover other bugs -- you will. But those bugs might have lurked undiscovered because you were too busy fighting buffer overflows and UAFs. Any given team of engineers has only so much time and energy; with fewer bug types to eliminate, the same team can get closer to bug-free. This is why the My Little Pony character alter of your average 25-year-old trans furry plural system wearing uwu kawaii programming socks, working in Rust, can code circles around even the most jaded C grognard with decades of experience -- and will be writing an OS kernel or driver near you. > I don't know. I do see the value Rust and Go create, but if we follow good software practices in C, don't you think we could ship decent safe software there too? Or are all C programs inherently buggy by default? All C programs but the most trivial are inherently buggy by default. As I put it, C is unsafe at any speed. Theoretically, it should be possible to establish sound disciplines and best practices to ensure safe C code, but experience has taught us that C is so full of potholes and footguns that it is practically impossible to write safe C even for experienced developers.