I can think of ten security-critical applications/services off the top of my head which are will never accept patches/changes to rewrite some/all of them in memory-safe languages.
I appreciate the goal of using languages better suited to memory-safety, but when I look at CVE lists including the same recurring projects I can't help thinking that the bounties here are not going to help.
(For example imagemagick/graphicmagic, the linux kernel, even wordpress/jenkins plugins, and similar things are regular candidates for security issues - and they're not going to get rewritten/modified-in-place to use rust/golang any time soon.)
WordPress is written in PHP and Jenkins is written in Java. These are already memory-safe languages. Security problems in their plugins rarely if ever derive from memory safety issues.
Which might be eligible for a bounty under this program, but I doubt the kernel itself will have parts of it written in a memory-safe language anytime soon.
I appreciate the goal of using languages better suited to memory-safety, but when I look at CVE lists including the same recurring projects I can't help thinking that the bounties here are not going to help.
(For example imagemagick/graphicmagic, the linux kernel, even wordpress/jenkins plugins, and similar things are regular candidates for security issues - and they're not going to get rewritten/modified-in-place to use rust/golang any time soon.)