5 ms·

>But I was always acutely aware that it only took one team member to declare a void * to an unbounded array for things to break out of that carefully constructe

>But I was always acutely aware that it only took one team member to declare a void * to an unbounded array for things to break out of that carefully constructed illusion of a safe jail. This is why code reviews are a thing. If you have competent programmers, with a CR process as part of CI/CD pipeline, you really don't need language features to handhold programming.

maximilianburke 4y ago
Even with the best code reviews, even with the best development practices, even with the most comprehensive automated testing processes, you still do need a language to help you. Case in point, even SQLite still has CVEs relating to memory safety: https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html
- junofan 4y ago
  I dunno, those bugs look mostly no- or low-impact. Saying somebody needs a language for that is a bit strong in my opinion.
  - slimsag 4y ago
    The page itself literally leads with multiple extensive statements about how the sqlite CVEs are exaggerated and inaccurate: > Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims. Also how most CVEs require arbitrary SQL injection (and if you have this access, you're screwed already): > Almost all CVEs written against SQLite require the ability to inject and run arbitrary SQL. It also explains that: > Few real-world applications meet either of these preconditions, and hence few real-world applications are vulnerable, even if they use older and unpatched versions of SQLite. --- It also explains that many CVEs are denial-of-service due to division-by-zero, which in Rust can only be caught by using the opt-in `checked_div` so would be equally safe in C and Rust(?)
    - skissane 4y ago
      It is true that a lot of people like to file CVEs for extremely theoretical security issues. See for example - https://nvd.nist.gov/vuln/detail/CVE-2023-0687 https://nvd.nist.gov/vuln/detail/CVE-2023-0687 The CVE is correct that the “gmon” component of the GNU C Library contains memory corruption bugs. In fact, I’ve found even more than the specific one that CVE is about. But, the claim that this is a security vulnerability is a bit silly. These are profiler functions, which are usually only called in non-production builds with profiling enabled (gcc -pg), and even then only from CRT startup code. It is rather unlikely an attacker can exploit any of these bugs in them without already having the ability to run arbitrary code in the process, at which point they don’t need these functions, they’ve already got all these bugs have to give them.
      - steveklabnik 4y ago
        Yeah, this kind of thing is tricky. Rust has had some CVEs filed against the standard library that are CVEs because of Rust's guarantees. Same issues existed in the C++ standard library but since it's UB, not a CVE there.
        saagarjha 4y ago
        Do the C++ libraries require changes as a result of these issues?
        steveklabnik 4y ago
        Nope, their docs just say "don't do that" and so you're expected not to do that.
        saagarjha 4y ago
        Ok, so this isn't an issue, right?
        4y ago
shaunsingh0207 4y ago
Code reviews are great, competent programmers are also great. Even the best programmers make mistakes. Additionally, the easier memory safety is, the more time those competent programmers can devote to work on new ideas instead of babysitting code.
simplotek 4y ago
Code reviews don't replace automatic tests or even linters. What leads you to believe they replace memory management errors?
jacquesm 4y ago
I don't think I can agree with this. Competent programmers are no silver bullet against whole classes of possible errors. Mistakes can be made, mistakes can be missed during code review. The vulnerability repositories are full of those.
sophacles 4y ago
You call it handholding. I call it partial automation of code review. Why waste expensive hours of my co-workers' time when I can have a program do it in seconds for a few pennies of electricity?

maximilianburke 4y ago

Even with the best code reviews, even with the best development practices, even with the most comprehensive automated testing processes, you still do need a language to help you. Case in point, even SQLite still has CVEs relating to memory safety: https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html

junofan 4y ago
I dunno, those bugs look mostly no- or low-impact. Saying somebody needs a language for that is a bit strong in my opinion.
- slimsag 4y ago
  The page itself literally leads with multiple extensive statements about how the sqlite CVEs are exaggerated and inaccurate: > Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims. Also how most CVEs require arbitrary SQL injection (and if you have this access, you're screwed already): > Almost all CVEs written against SQLite require the ability to inject and run arbitrary SQL. It also explains that: > Few real-world applications meet either of these preconditions, and hence few real-world applications are vulnerable, even if they use older and unpatched versions of SQLite. --- It also explains that many CVEs are denial-of-service due to division-by-zero, which in Rust can only be caught by using the opt-in `checked_div` so would be equally safe in C and Rust(?)
  - skissane 4y ago
    It is true that a lot of people like to file CVEs for extremely theoretical security issues. See for example - https://nvd.nist.gov/vuln/detail/CVE-2023-0687 https://nvd.nist.gov/vuln/detail/CVE-2023-0687 The CVE is correct that the “gmon” component of the GNU C Library contains memory corruption bugs. In fact, I’ve found even more than the specific one that CVE is about. But, the claim that this is a security vulnerability is a bit silly. These are profiler functions, which are usually only called in non-production builds with profiling enabled (gcc -pg), and even then only from CRT startup code. It is rather unlikely an attacker can exploit any of these bugs in them without already having the ability to run arbitrary code in the process, at which point they don’t need these functions, they’ve already got all these bugs have to give them.
    - steveklabnik 4y ago
      Yeah, this kind of thing is tricky. Rust has had some CVEs filed against the standard library that are CVEs because of Rust's guarantees. Same issues existed in the C++ standard library but since it's UB, not a CVE there.
      - saagarjha 4y ago
        Do the C++ libraries require changes as a result of these issues?
        steveklabnik 4y ago
        Nope, their docs just say "don't do that" and so you're expected not to do that.
        saagarjha 4y ago
        Ok, so this isn't an issue, right?
        4y ago

shaunsingh0207 4y ago

Code reviews are great, competent programmers are also great. Even the best programmers make mistakes. Additionally, the easier memory safety is, the more time those competent programmers can devote to work on new ideas instead of babysitting code.

simplotek 4y ago

Code reviews don't replace automatic tests or even linters. What leads you to believe they replace memory management errors?

jacquesm 4y ago

I don't think I can agree with this. Competent programmers are no silver bullet against whole classes of possible errors. Mistakes can be made, mistakes can be missed during code review. The vulnerability repositories are full of those.

sophacles 4y ago

You call it handholding. I call it partial automation of code review. Why waste expensive hours of my co-workers' time when I can have a program do it in seconds for a few pennies of electricity?