[stevekemp]

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.)

[philipkglass]

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.

[stevekemp]

Bad examples, yes. Sorry!

Pretend I wrote gstreamer, wireshark, or similar.

[kingkilr]

The kernel maintainers have actively expressed interest in having upstream support for writing kernel modules in Rust!

[saagarjha]

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.

[kingkilr]

Lots of drivers, network protocols, etc. in the kernel, and they're most of the attack surface -- not the scheduler :-)

We have to approach this as a question of how, not if. When we do that, we can change computer security.