5 ms·

Can you clarify why?

by eloff 5y ago

masklinn 5y ago
The amount of code which would have to be `unsafe` in a library like sqlite would be absolutely minuscule if it would exist at all, and much easier to check for than literally all of the codebase?
- eloff 5y ago
  Well, yeah, it's safer, there's no question about it. Is it sufficiently much safer to warrant the massive investment and the bugs (including security bugs) which will result from a rewrite? If I was the project manager I would not sign off on that. This is a volunteer project. Someone can of course do all that work free of charge, but they'd really just creating a fork of sqlite unless they also get most of the other major volunteers to agree.
tptacek 5y ago
I don't think we understand enough about computer science or computer engineering (or something in the middle of those two things) to deliver large-scale C projects with rich, flexible interfaces safely. The last 20 years has just been a sequence of events where we've been surprised by new oversights, from buffer overflows to integer mishandling to uninitialized variables to UB. These problems compound; they're never solved, but rather beaten into development teams (at least the conscientious ones) and so even the decades-old problems recur, because it's not enough to know about the general pattern of a problem, you also have to viscerally understand all the combinatorics of those problems and all the new code that you write, all of which has the potential to create some new scenario that allows a well-known vulnerability to re-emerge. And even if you manage to clean the Augean Stables this way, you're still S.O.L. when the next new memory corruption bug class is discovered. A mug's game, a bad bet. You can use formal methods to sidestep this! But my argument would be that at that point, you're really writing C In Name Only. By all means, if the aesthetics of Rust are that painful to you (I get it!), write C against a formal verifier. :)
- eloff 5y ago
  I agree with this for the most part. But just because you use Rust doesn't mean you have no security issues - there are still plenty of ways to go wrong, including integer overflow if you're using "as" conversions instead of checked conversions. But there's no doubt it eliminates a whole class of issues and makes others much less likely (and verifiably so.) For a greenfield project, you shouldn't use C or C++ today, unless you need some huge big C++ library (e.g. game engine). For sqlite which has 100% branch coverage and is quite well written, I don't think a rewrite makes sense. You'll surely introduce more bugs, including security bugs, than you fix. The cost seems too high. It'd be better to just fix security issues as they come up (and try to clean up bits of code that could be problematic.)
  - pdimitar 5y ago
    I love Rust but I agree with you. For sqlite in particular the argument seems heavily tilted against a rewrite.

Can you clarify why?

by eloff 5y ago

Can you clarify why?

The amount of code which would have to be `unsafe` in a library like sqlite would be absolutely minuscule if it would exist at all, and much easier to check for than literally all of the codebase?

eloff 5y ago
Well, yeah, it's safer, there's no question about it. Is it sufficiently much safer to warrant the massive investment and the bugs (including security bugs) which will result from a rewrite? If I was the project manager I would not sign off on that. This is a volunteer project. Someone can of course do all that work free of charge, but they'd really just creating a fork of sqlite unless they also get most of the other major volunteers to agree.

tptacek 5y ago

I don't think we understand enough about computer science or computer engineering (or something in the middle of those two things) to deliver large-scale C projects with rich, flexible interfaces safely. The last 20 years has just been a sequence of events where we've been surprised by new oversights, from buffer overflows to integer mishandling to uninitialized variables to UB. These problems compound; they're never solved, but rather beaten into development teams (at least the conscientious ones) and so even the decades-old problems recur, because it's not enough to know about the general pattern of a problem, you also have to viscerally understand all the combinatorics of those problems and all the new code that you write, all of which has the potential to create some new scenario that allows a well-known vulnerability to re-emerge. And even if you manage to clean the Augean Stables this way, you're still S.O.L. when the next new memory corruption bug class is discovered. A mug's game, a bad bet. You can use formal methods to sidestep this! But my argument would be that at that point, you're really writing C In Name Only. By all means, if the aesthetics of Rust are that painful to you (I get it!), write C against a formal verifier. :)

eloff 5y ago
I agree with this for the most part. But just because you use Rust doesn't mean you have no security issues - there are still plenty of ways to go wrong, including integer overflow if you're using "as" conversions instead of checked conversions. But there's no doubt it eliminates a whole class of issues and makes others much less likely (and verifiably so.) For a greenfield project, you shouldn't use C or C++ today, unless you need some huge big C++ library (e.g. game engine). For sqlite which has 100% branch coverage and is quite well written, I don't think a rewrite makes sense. You'll surely introduce more bugs, including security bugs, than you fix. The cost seems too high. It'd be better to just fix security issues as they come up (and try to clean up bits of code that could be problematic.)
- pdimitar 5y ago
  I love Rust but I agree with you. For sqlite in particular the argument seems heavily tilted against a rewrite.