Re:Eliminating Memory Safety Vulnerabilities at the Source
by 0xbadcafebee on Thursday September 26, 2024 @01:43PM
(#41661122)
Take that to its logical end: a language designed with high-level functions to automate all possible work that, if left to a human to craft, would expose security vulnerabilities.
You know what you have there? A new method for developing software.
If we just switch languages every time we have another class of vuln that we want to eliminate, it will take us 1,000 years to get them all.
Or we could just get them all today by fundamentally rethinking how we write software.
The problem isn't software. The problem is humans writing software. There are bugs because we are using a highly fallible process to create software. If we want to eliminate the bugs, we have to change how the software is created.
It's absolutely possible to write a reasonably usable language that makes injection/escaping/pollution/datatype confusion errors nearly impossible, but it would involve language support and rewriting most libraries--just like memory safety did. Unfortunately we are moving in the opposite direction (I'm still angry about javascript backticks, a feature seemingly designed solely to allow the porting of php-style sql injection errors)