Mitigating Memory Safety Issues in Open Source Software

https://compcert.org/ > The CompCert project investigates the formal verification of realistic compilers usable for critical embedded software. Such verified compilers come with a mathematical, machine-checked proof that the generated executable code behaves exactly as prescribed by the semantics of the source program.

https://frama-c.com/ > Frama-C gathers several static and dynamic analysis techniques in a single collaborative framework. The collaborative approach of Frama-C allows static analyzers to build upon the results already computed by other analyzers in the framework.

https://www.cprover.org/cbmc/ > CBMC is a Bounded Model Checker for C and C++ programs. ... CBMC verifies memory safety (which includes array bounds checks and checks for the safe use of pointers), checks for ex­cep­tions, checks for various variants of undefined behavior, and user-specified as­ser­tions.

I see references to "fixing" C and rewriting. An alternative would be to transpile a memory safe, easy to program language such as python3 and generate code in a memory safe language.

Since I don't know which one of these is the best, I have implemented basic (as in fibonacci and a simple class) in several languages.

I hope more effort is spent on writing code in small statically typed languages and generating memory safe code.

https://github.com/adsharma/py2many

> but if they rewrite the project in rust, why _shouldn't_ they control that project? If other people choose to switch, then it's not wrong for them to move, and not wrong for to google gain control of those users.

I think the issue is the more critical projects Google controls, the more they can make decisions by fiat. Those decisions will favor Google's interests, and could sacrifice everyone else's interests in some way.

It's sort of like web browsers. My understanding is that Chrome is so dominant that Google can basically dictate HTML standards at this point, or at least effectively push them in directions that are favorable to its ad-based business.

> One is the highly dynamic nature of cargo dependencies. libfoo might depend on a myriad of crates transitively and rust simply is too young to provide any experience in how long they will be available or supported. And no, it is generally not a good idea to update to new feature releases for security updates. This is something that stable distributions explicitly try to avoid.

crates.io is designed so that dependencies put up on it remain available forever, and that the only other cargo related dependencies also have to be hosted on crates.io - solving the availability problem.

Of course if you're trying to backport a security fix to an old version of a transitive dependency that (like the non-transitive dependency) is no longer supported, you do have to make that backport. Once you make that backport it's easy to update the version of the transitive dependency with a [patch] section in the top level Cargo.toml.

> The second problem is the compiler itself. Any change in libfoo-1.2 might require a newer version of rust.

This is already mitigated in multiple ways. As discussed before, people do make sure to support old versions of compilers, you don't need to have a compiler on your target platform anyways. But moreover, the amount new language features make backporting difficult is dwarfed by the amount that internal library changes do.