Fish in a Barrel Memory Safety Bounty Program (opens in new tab)

One example: librsvg was rewritten from C into Rust, gradually, while retaining the C API:

https://gitlab.gnome.org/GNOME/librsvg https://people.gnome.org/~federico/news-2016-10.html

(I do not necessarily endorse this, as I find the dependency on a Rust compiler of very recent vintage, to be much more annoying than depending on any decent C compiler from the last 7 years or so.)

It's a great question!

a) It being acceptable to upstream is mandatory to receive a bounty, so a starting point might be: pick projects whose maintainers are sick of dealing with ASAN reports! b) A huge number of people get their libpng or anything else via a package manager like Debian. Debian packages libpng from upstream. If libpng changes something about it's implementation, that'll be reflected in a future debian release.

This is going to be a long process, but we firmly believe the question has to be "how" not "if". If you've got better ideas for how we can promote the transition to memory safe languages, please let us know!

Project coordination with opensource projects is a really difficult problem where you simply can't win. Sometimes a project is just bad and needs an overhaul even if it means 40% of the code has to be thrown out. Sometimes people fork the project but most of the time a project is started from scratch because it means full ownership and therefore a more productive working environment.

The number of times I've seen something that amounts to a 1-3 line code change being discussed for hours is absurd. If you are a new contributor who wants to help out by writing code it often feels like you are making the maintainers work harder than if you had done nothing for the project.

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

>Partially (or completely) migrate the project to a memory-safe language (e.g., convert one of the decoder/encoders in an image parsing library to Rust)

For this kind of contribution, I'm not sure there'll be too much spam. Eg most of the "Rewrite It In Rust"-kind of spam like [1] is people making suggestions, not actual PRs, because it does actually take effort. But...

>Add bindings making the library usable from Rust or Swift (e.g., adding official Swift bindings to an image parsing library)

... I'm not sure about this one. It could be as mindless as "just run bindgen on the C header, wrap it in a -sys crate" and send a PR. I don't actually understand why that kind of contribution is being awarded though, since having safe bindings doesn't make the actual library any safer. Furthermore, bindings don't need to be contributed to upstream, just like all the Rust bindings libraries today are mostly third-party.

[1]: https://www.postgresql.org/message-id/CAASwCXdQUiuUnhycdRvrU...

It's $100-$500, that's not even a moderate amount of money for the amount of work required. It seems to me to be more of an incentive, and a nice reward for doing good work that helps people.

Those of us who organized this both have a long history of involvement in open source. If we have even an iota of this becoming a problem, we will a) be incredibly saddened, b) figure out how to restructure the rules to address the behavior we see.

Right, there a lot of projects that value the fact that their project builds on a lot of platforms, and that they can support old or strange systems that many memory-safe languages do not target (or only do so "unofficially" with some third-party fork of varying quality). I have met a lot of people who brush this off as "yeah but why should we care about those crufty old things, nobody uses them" but such an attitude does not endear itself well.