- it conflates data race protection with memory safety, and it does so inconsistently. Java and C# are mentioned as MSLs and yet they totally let you race. More fundamentally, data races aren’t the thing that attackers exploit except when those data races do lead to actual memory corruption (like use after free, double free, out of bounds, access to allocator metadata etc). So it’s more precise to not mention data races freedom as a requirement for memory safety, both because otherwise languages like Java and C# don’t meet the definition despite being included in the list and because data races in the presence of memory safety are not a big deal from a security standpoint.
- The document fails to mention to mention Fil-C. It would be understandable if it was mentioned with caveats (“new project”, “performance blah blah”) but not mentioning it at all is silly.
Memory safety is like the global warming of the software industry. Millions of careers depend on treating the problem and nobody wants the cure. I imagine Fil-C would be about as popular with the DoD as geoengineering / nuclear power are with environmentalists. Your project is so good that it's like a glitch in the matrix. Only people like Carmack and Musk are going to understand its value.
A big thing missing is swapping out dependencies in unsafe languages for ones written in safe languages.
Usually there are only a couple places that actually deal with user controlled data, so switching to safe dependencies for things like making thumbnails for pdf files can be effective.
Edit: One more thing is compiling unsafe code to web assembly or other forms of sandboxing it was not mentioned.
Incremental replacement of critical dependencies also offers a practical migration path for large legacy codebases where complete rewrites are economically infeasible.
Two big problems in this document:
- it conflates data race protection with memory safety, and it does so inconsistently. Java and C# are mentioned as MSLs and yet they totally let you race. More fundamentally, data races aren’t the thing that attackers exploit except when those data races do lead to actual memory corruption (like use after free, double free, out of bounds, access to allocator metadata etc). So it’s more precise to not mention data races freedom as a requirement for memory safety, both because otherwise languages like Java and C# don’t meet the definition despite being included in the list and because data races in the presence of memory safety are not a big deal from a security standpoint.
- The document fails to mention to mention Fil-C. It would be understandable if it was mentioned with caveats (“new project”, “performance blah blah”) but not mentioning it at all is silly.
They're not going to mention a single-person experimental project that has 900 stars on GitHub.
This is meant to be a practical strategy that can be implemented nation-wide, without turning into another https://xkcd.com/2347
> They're not going to mention a single-person experimental project that has 900 stars on GitHub.
Seems like a bad way to pick technology.
They do mention things like TRACTOR. Fil-C is far ahead of any project under the TRACTOR umbrella.
> This is meant to be a practical strategy that can be implemented nation-wide, without turning into another https://xkcd.com/2347
The solution to that is funding the thing that is essential, rather than complaining that an essential thing is unfunded. DOD could do that
Memory safety is like the global warming of the software industry. Millions of careers depend on treating the problem and nobody wants the cure. I imagine Fil-C would be about as popular with the DoD as geoengineering / nuclear power are with environmentalists. Your project is so good that it's like a glitch in the matrix. Only people like Carmack and Musk are going to understand its value.
jart putting Carmack and Musk at the same level is a bit sad and revealing, no wonder the downvotes.
A big thing missing is swapping out dependencies in unsafe languages for ones written in safe languages.
Usually there are only a couple places that actually deal with user controlled data, so switching to safe dependencies for things like making thumbnails for pdf files can be effective.
Edit: One more thing is compiling unsafe code to web assembly or other forms of sandboxing it was not mentioned.
Incremental replacement of critical dependencies also offers a practical migration path for large legacy codebases where complete rewrites are economically infeasible.
reducing security incidents for modern software developments