3 ms·

I don't think a rust version of sqlite would make sense, rewriting a very mature and well tested library rarely makes sense. Only if either: - there are anywa

I don't think a rust version of sqlite would make sense, rewriting a very mature and well tested library rarely makes sense. Only if either: - there are anyway some major changes comming - or major problems/improvements in maintainability and better external dev commitment/support could rewriting it make sense IMHO. Lets be honest many (most?) of the "recent" (~3years) security bugs sqlite had would most likely not have been prevented by using rust, go or similar. EDIT: I guess the biggest drawback of C is that it keeps contributors away, but I also might keep some of the contributors projects like sqlite might not want to have away. So depending on the maintainer it might be seen as a benefit not a drawback.

tptacek 5y ago
The problem with the first sentence of this comment is that it also justifies keeping stuff like ImageMagick around.
woodruffw 5y ago
> Lets be honest many (most?) of the "recent" (~3years) security bugs sqlite had would most likely not have been prevented by using rust, go or similar. Using SQLite's CVE list from 2020[1], we see 12 vulnerabilities: * Two NULL pointer dereferences; it's impossible to produce a NULL reference in safe Rust. * Two integer overflows; Rust makes these harder, but not impossible. * Three UAFs; these are impossible in safe Rust. * One uncategorized segfault; there are impossible in safe Rust barring environmental constraints (like a stack overflow from unchecked recursion). * One segmentation fault from incorrect object initialization; this is impossible in safe Rust. * 3 SQL and table-level bugs; Rust is unlikely to have helped with these. By my count, that's 6/12 bugs are would be impossible in plain old safe Rust, and another 3/12 that would likely be prevented by normal best practices in Rust. I still don't think this necessarily means that we should drop everything and rewrite SQLite in Rust, but the raw numbers don't back up the claim that doing so wouldn't eliminate the actual security bugs that SQLite is seeing. [1]: https://www.cvedetails.com/vulnerability-list/vendor_id-9237/year-2020/Sqlite.html https://www.cvedetails.com/vulnerability-list/vendor_id-9237...
- PaulDavisThe1st 5y ago
  The 3/12 that safe Rust would have prevented would likely have been prevented by enforcing the use of current tools for C. Since neither Rust safety or lint-ish safety are enforced, I think this is a reasonable comparison.
  - woodruffw 5y ago
    Show me a project that claims to consistently use static analysis tools for C and doesn’t ignore them, and I’ll show you a liar! But more seriously: Rust’s toolchain comes with linting built in, and the community as a whole is much better about applying and responding to static analysis results than the C ecosystem is. And that’s even before we get to false positives, which (subjectively) C static analysis tools seem to spit out a great deal more often. And I say all of that as someone who’s currently doing whole-program static analysis of C and C++! It’s not that you can’t do it, it’s degrees of ease and a culture of stringency that’s lacking.
    - j16sdiz 5y ago
      rust's static analysis keeps improving in new compiler version. BUT, keeps improving == keep changing. For a library like sqlite, it need to maintain compiler compatibility. It is difficult to track a "live" language.
      - woodruffw 5y ago
        Certainly! Lots of compiler churn means lots of downstream churn. However, for what it’s worth: I’m currently maintaining around 50k lines of Rust (both public and private code), and my experience with compiler changes has been remarkably painless: I get a couple of new warnings (usually from clippy) in the CI every few months, fix them, and move on with my life. Nothing ever fundamentally breaks: I could ignore the warnings and roll them all up into a single change every 6 months if I chose to.
        dathinab 5y ago
PaulDavisThe1st 5y ago
>I guess the biggest drawback of C is that it keeps contributors away There's this idea floating around in some circles that if you could just adopt technology X, more people would contribute to a project. I myself was guilty of this ... believing that if we added a web frontend to the DAW I've worked on for 21 years, all those JS/webtech developers would show up. There's no platform or language you could choose for SQLite that would increase the number of contributors. C is already a wildly popular programming language, with far, far more practicing users than Rust. Rust may be The Cool New Thing at present, and in time it may possibly grow to something much bigger, bigger even than the C/C++ universe. But that's not true right now, and it also wouldn't be true even if SQLite was implemented using some impossibly performant JS or its cousin.
- cozzyd 5y ago
  Yeah that sounded way off base to me. Regardless of relative merits, how many rust developers are there that don't know C? Probably not a huge number. How many C developers have never seen a line of rust? Probably an order of magnitude more than there are rust developers.

tptacek 5y ago

The problem with the first sentence of this comment is that it also justifies keeping stuff like ImageMagick around.

woodruffw 5y ago

> Lets be honest many (most?) of the "recent" (~3years) security bugs sqlite had would most likely not have been prevented by using rust, go or similar. Using SQLite's CVE list from 2020[1], we see 12 vulnerabilities: * Two NULL pointer dereferences; it's impossible to produce a NULL reference in safe Rust. * Two integer overflows; Rust makes these harder, but not impossible. * Three UAFs; these are impossible in safe Rust. * One uncategorized segfault; there are impossible in safe Rust barring environmental constraints (like a stack overflow from unchecked recursion). * One segmentation fault from incorrect object initialization; this is impossible in safe Rust. * 3 SQL and table-level bugs; Rust is unlikely to have helped with these. By my count, that's 6/12 bugs are would be impossible in plain old safe Rust, and another 3/12 that would likely be prevented by normal best practices in Rust. I still don't think this necessarily means that we should drop everything and rewrite SQLite in Rust, but the raw numbers don't back up the claim that doing so wouldn't eliminate the actual security bugs that SQLite is seeing. [1]: https://www.cvedetails.com/vulnerability-list/vendor_id-9237/year-2020/Sqlite.html https://www.cvedetails.com/vulnerability-list/vendor_id-9237...

PaulDavisThe1st 5y ago
The 3/12 that safe Rust would have prevented would likely have been prevented by enforcing the use of current tools for C. Since neither Rust safety or lint-ish safety are enforced, I think this is a reasonable comparison.
- woodruffw 5y ago
  Show me a project that claims to consistently use static analysis tools for C and doesn’t ignore them, and I’ll show you a liar! But more seriously: Rust’s toolchain comes with linting built in, and the community as a whole is much better about applying and responding to static analysis results than the C ecosystem is. And that’s even before we get to false positives, which (subjectively) C static analysis tools seem to spit out a great deal more often. And I say all of that as someone who’s currently doing whole-program static analysis of C and C++! It’s not that you can’t do it, it’s degrees of ease and a culture of stringency that’s lacking.
  - j16sdiz 5y ago
    rust's static analysis keeps improving in new compiler version. BUT, keeps improving == keep changing. For a library like sqlite, it need to maintain compiler compatibility. It is difficult to track a "live" language.
    - woodruffw 5y ago
      Certainly! Lots of compiler churn means lots of downstream churn. However, for what it’s worth: I’m currently maintaining around 50k lines of Rust (both public and private code), and my experience with compiler changes has been remarkably painless: I get a couple of new warnings (usually from clippy) in the CI every few months, fix them, and move on with my life. Nothing ever fundamentally breaks: I could ignore the warnings and roll them all up into a single change every 6 months if I chose to.
      - dathinab 5y ago

PaulDavisThe1st 5y ago

>I guess the biggest drawback of C is that it keeps contributors away There's this idea floating around in some circles that if you could just adopt technology X, more people would contribute to a project. I myself was guilty of this ... believing that if we added a web frontend to the DAW I've worked on for 21 years, all those JS/webtech developers would show up. There's no platform or language you could choose for SQLite that would increase the number of contributors. C is already a wildly popular programming language, with far, far more practicing users than Rust. Rust may be The Cool New Thing at present, and in time it may possibly grow to something much bigger, bigger even than the C/C++ universe. But that's not true right now, and it also wouldn't be true even if SQLite was implemented using some impossibly performant JS or its cousin.

cozzyd 5y ago
Yeah that sounded way off base to me. Regardless of relative merits, how many rust developers are there that don't know C? Probably not a huge number. How many C developers have never seen a line of rust? Probably an order of magnitude more than there are rust developers.