5 ms·
Random non-trolling question by someone who is genuinely unfamiliar with the problem space: is it worthwhile rewriting these utilities in a language that avoids
by SCdF 12y ago
Random non-trolling question by someone who is genuinely unfamiliar with the problem space: is it worthwhile rewriting these utilities in a language that avoids these sorts of problems? Is it because they're far more complicated than I realise and rewrites would create more problems that it solves? It is because until Rust is 1.0 there isn't a language that is suitable? Or am I missunderstanding the problem completely?
My reasoning comes from the vast majority of problems I notice being from the edge cases in managing memory, and so if I understand correctly there is a whole suite of languages that mostly remove these problems.
- zeeg 12y agoIf you think introducing Rust (as an example) solves these kinds of problems you are sorely mistaken. Languages can make it easier for some things, but they're not a magical fix all. If it weren't this problem it would be something else, something that even "the great mythical Rust" can't prevent.
- rian 12y agoAgree that Rust is not a magical fix-all solution. Rust ensures memory safety and prevents data-races but there are still a whole universe of programming-error-induced vulnerabilities that Rust will happily compile and run. Don't get me wrong, using a more restrictive language will help but it's not a fully-baked solution. We need more third-party tools to help us automatically verify the correctness of our programs. It shouldn't stop at compilers.
- dietrichepp 12y ago> A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process. Rust, as an example, prevents exactly these kinds of problems.
- lawnchair_larry 12y agoNo, rewriting things in memory safe languages is absolutely something that should be done where it makes sense. There is no good reason to write things like ntpd in C anymore. Anyone who says you'll just have a new set of similar issues is full of crap. You'll likely have issues, but ruling out memory corruption out the door is an indisputable win.
- zzzcpan 12y agoNtpd should be replaced with something different, not rewritten. There is no reason to rewrite it. But I agree, there is no good reason to write such things in C anymore.
- rian 12y agoWell, there are still some good reasons to write things in C. For one it's standardized. Two it's ubiquitous. I agree that projects should have a way to verify with 100% accuracy the memory safety of their code. One way to do that is to rewrite in another language. Another way to do that is to use a static analyzer that lists out all unsafe operations in your codebase. Here's one http://goto.ucsd.edu/csolve/ http://goto.ucsd.edu/csolve/. Adds an extra build step / precommit-hook but IMO the cost/benefit is much better than rewriting your project. After all, we can't just rewrite our code every time a new safe language comes out.
- deleted 12y ago[deleted]
- lawnchair_larry 12y agoYou don't seem to understand this problem space.
- zzzcpan 12y agoNowadays it is possible to catch these kinds of errors ahead of time and at runtime with some help from static analyzers and other special tools, like AddressSanitizer. This report itself is likely to be the result of such work. So, rewrite is not worthwhile if your reasoning is to prevent edge cases in managing memory.