4 ms·

It is about safe and unsafe implementations rather than safe and unsafe languages.

titzer 6y ago
This specific type of vulnerability and the tens of thousands of similar ones like it would absolutely have been prevented by a safe programming language.
- dependenttypes 6y ago
  This specific type of vulnerability would not be an issue in a safe C implementation for example, just like it would be an issue in an unsafe rust implementation.
  - Dylan16807 6y ago
    "safe C" and "unsafe Rust" sound like variant languages to me.
    - dependenttypes 6y ago
      How is "safe C" a variant language when it is within what the standard allows?
      - Dylan16807 6y ago
        The unsafeness of C is pretty widespread and fundamental. Whatever code you end up with is either going to be incompatible with normal compilers, or it's going to be so full of library calls that you can barely recognize it as C anymore. Unless you count sandboxing the entire program, and allowing errors inside the sandbox as long as they don't escape. Then C-to-WASM would be a safe C compiler, I guess.
        dependenttypes 6y ago
        > Whatever code you end up with is either going to be incompatible with normal compilers I do not believe that this is necessarily the case.
  - titzer 6y ago
    There have been research projects that have attempted to make a standards compliant "safe C" a number of different times. You either end up with a 3x execution time overhead, only support a subset, or break programs that do unsafe type punning. As a result, this is not viable.
erik_seaberg 6y ago
Can we name any programmers who are actually capable of a safe implementation using an unsafe language? DJB failed, Knuth's code has bugs, how can I expect you or I to succeed?
- dependenttypes 6y ago
  I am not talking about safe implementations of programs but rather safe implementations of languages. A (kind of bad example because it does not catch everything) is the address sanitiser that clang and gcc have.
- peterwwillis 6y ago
  That's a good point, but on the other hand, who wrote the languages? Is it possible for a human to write a language which another human can use and create no bugs? In either case - unsafe language and safe implementation, safe language and unsafe implementation - there is the possibility for bugs, and definitely security ones. Just because you can't cause integer overflow doesn't mean you can't exfiltrate petabytes of data. I think the major security consideration should be a comprehensive review of the entire system. Regardless of the language or implementation, a regular architectural and non-functional review of all the components in a systematic way is going to provide more security gains than any other single thing. Maybe we should be focusing less on the tools we use and more on improving that workflow.

This specific type of vulnerability and the tens of thousands of similar ones like it would absolutely have been prevented by a safe programming language.

dependenttypes 6y ago
This specific type of vulnerability would not be an issue in a safe C implementation for example, just like it would be an issue in an unsafe rust implementation.
- Dylan16807 6y ago
  "safe C" and "unsafe Rust" sound like variant languages to me.
  - dependenttypes 6y ago
    How is "safe C" a variant language when it is within what the standard allows?
    - Dylan16807 6y ago
      The unsafeness of C is pretty widespread and fundamental. Whatever code you end up with is either going to be incompatible with normal compilers, or it's going to be so full of library calls that you can barely recognize it as C anymore. Unless you count sandboxing the entire program, and allowing errors inside the sandbox as long as they don't escape. Then C-to-WASM would be a safe C compiler, I guess.
      - dependenttypes 6y ago
        > Whatever code you end up with is either going to be incompatible with normal compilers I do not believe that this is necessarily the case.
- titzer 6y ago
  There have been research projects that have attempted to make a standards compliant "safe C" a number of different times. You either end up with a 3x execution time overhead, only support a subset, or break programs that do unsafe type punning. As a result, this is not viable.

erik_seaberg 6y ago

Can we name any programmers who are actually capable of a safe implementation using an unsafe language? DJB failed, Knuth's code has bugs, how can I expect you or I to succeed?

dependenttypes 6y ago
I am not talking about safe implementations of programs but rather safe implementations of languages. A (kind of bad example because it does not catch everything) is the address sanitiser that clang and gcc have.
peterwwillis 6y ago
That's a good point, but on the other hand, who wrote the languages? Is it possible for a human to write a language which another human can use and create no bugs? In either case - unsafe language and safe implementation, safe language and unsafe implementation - there is the possibility for bugs, and definitely security ones. Just because you can't cause integer overflow doesn't mean you can't exfiltrate petabytes of data. I think the major security consideration should be a comprehensive review of the entire system. Regardless of the language or implementation, a regular architectural and non-functional review of all the components in a systematic way is going to provide more security gains than any other single thing. Maybe we should be focusing less on the tools we use and more on improving that workflow.