5 ms·

I despise this security-first attitude. It just leads to so much mental fatigue everywhere and any step is a potential minefield. It's ruining programming.

by bitL 4y ago

ironmagma 4y ago
> any step is a potential minefield That's the exact problem with C. It's the tool, not the attitude, which is a problem.
- flohofwoe 4y ago
  Securely containing untrusted user code so that it can't do any harm is ultimately the responsibility of the OS, or whatever sandbox the code is running in. Language-level memory safety is useful for eliminating an important class of bugs, but if those bugs can be exploited to escape the sandbox, then that's the problem of the sandbox, not of the buggy program running in that sandbox. So please, by all means, write the sandbox itself in a memory safe language like Rust, but requiring the same for all code running inside the sandbox is nothing more than an admission of failure.
  - timbit42 4y ago
    What if the sandbox, kernel, device drivers are written in C? Sounds like a good case against C for these uses.
    - flohofwoe 4y ago
      Yes, I fully agree! But such subtleties are usually overlooked by the 'C users are criminals' crowd ;)
  - ilyt 4y ago
    That's pretty limited way to look at it. You don't need to escape the sandbox to do harm. You can have your app in perfect sandbox where nothing can escape then have a memory safety bug inside allowing user to get to the stuff of another user (because your sandboxed app talking with sandboxed database still have one set of credentials to do everything) There is of course https://xkcd.com/1200/ https://xkcd.com/1200/ for that. And no "move that separation to DB" also isn't a solution.
    - flohofwoe 4y ago
      I agree, same with popular multiplayer games for instance which could be exploited by memory safety bugs in the network protocol implementation. But these are cases where just implementing a couple of critical modules either with a memory-safe language, or using code generation (or both) to reduce the amount of 'manual bugs' go a long way. AFAIK exploits almost always happen in places where data comes into the system, so those are the places to focus on.
Gigachad 4y ago
Imagine any other engineering field complaining about safety being a mental drain.

I despise this security-first attitude. It just leads to so much mental fatigue everywhere and any step is a potential minefield. It's ruining programming.

by bitL 4y ago

I despise this security-first attitude. It just leads to so much mental fatigue everywhere and any step is a potential minefield. It's ruining programming.

ironmagma 4y ago

> any step is a potential minefield That's the exact problem with C. It's the tool, not the attitude, which is a problem.

flohofwoe 4y ago
Securely containing untrusted user code so that it can't do any harm is ultimately the responsibility of the OS, or whatever sandbox the code is running in. Language-level memory safety is useful for eliminating an important class of bugs, but if those bugs can be exploited to escape the sandbox, then that's the problem of the sandbox, not of the buggy program running in that sandbox. So please, by all means, write the sandbox itself in a memory safe language like Rust, but requiring the same for all code running inside the sandbox is nothing more than an admission of failure.
- timbit42 4y ago
  What if the sandbox, kernel, device drivers are written in C? Sounds like a good case against C for these uses.
  - flohofwoe 4y ago
    Yes, I fully agree! But such subtleties are usually overlooked by the 'C users are criminals' crowd ;)
- ilyt 4y ago
  That's pretty limited way to look at it. You don't need to escape the sandbox to do harm. You can have your app in perfect sandbox where nothing can escape then have a memory safety bug inside allowing user to get to the stuff of another user (because your sandboxed app talking with sandboxed database still have one set of credentials to do everything) There is of course https://xkcd.com/1200/ https://xkcd.com/1200/ for that. And no "move that separation to DB" also isn't a solution.
  - flohofwoe 4y ago
    I agree, same with popular multiplayer games for instance which could be exploited by memory safety bugs in the network protocol implementation. But these are cases where just implementing a couple of critical modules either with a memory-safe language, or using code generation (or both) to reduce the amount of 'manual bugs' go a long way. AFAIK exploits almost always happen in places where data comes into the system, so those are the places to focus on.

Gigachad 4y ago

Imagine any other engineering field complaining about safety being a mental drain.