True. But most other classes of bug are not security bugs by default in the way that memory safety bugs are.
Also half the software mentioned in that gist should never be used in security-focused applications anyway (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already doing it wrong)
The last study I saw was that 52% of security vulnerabilities were still basic memory safety vulnerabilities. Memory safety isn't the only thing, but it's still the biggest thing.
> (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already doing it wrong)
People run cat or awk on log files (where an attacker could easily craft particular data patterns) all the time. Maybe they shouldn't, but they do.
As for other kinds of bugs, yeah, that's inevitable, but I still prefer to have the memory safety bugs eliminated from the get go so I'd still say it's a worthy sacrifice to walk the road to safe tools one more time just for the memory safety.
So yeah, no need to rewrite tools in already memory safe languages but when it comes to C/C++ tools then yes, we need to rewrite them.
Sure that given enough resources, motivation and time, Anything is possible. But new code means bugs and uncertainty.
Some of the tools listed are not small if a one for one replacement is the target. Vim is listed??
How long before these tools are considered as matured and ready for production?
