Fish in a Barrel Memory Safety Bounty Program(github.com) |
Fish in a Barrel Memory Safety Bounty Program(github.com) |
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.)
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!
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 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.)
> A: The Fish in a Barrel Memory Safety Bounty only rewards contributions that are merged upstream. We strongly encourage people interested in pursuing a bounty to work with, not against, open source maintainers and to behave respectfully.
It's good to see this called out specifically, but I can't help but think this is attaching a monetary incentive to badger a project to accept a patch that at the very least requires changes to the project build system
Rust is memory safe only in documentation but not in practise.[1] Rather provide bounties for real memory safe languages. Rust is also neither type safe[2] nor concurrency safe[3].
1: eg https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao... but this is just the surface. alloca is not only unsafe but also security critical. Rust stack allocates too much unchecked.
2. https://doc.rust-lang.org/reference/unsafe-blocks.html
3. Races as eg with https://doc.rust-lang.org/reference/items/static-items.html?... requiring manual mutexes
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...
That said, we will consider level of effort as a component of our judging process when determining eligibility and bounty size.
Pretend I wrote gstreamer, wireshark, or similar.
I hope for your sake that you do, but just to be clear I don't think anyone in this thread is too concerned about whether you pay out the bounty or not. You can be as loose or as tight with your money as you'd like :)
The concern is from the point of view of the maintainers who will receive spam PRs / patches. Even if you don't pay out for that contribution, it will not unsend the PR / patch in the maintainer's mailbox.
Perhaps you can list some and why they were casualties of the Rust language rather than reasonable cleanup that would have happened in any rewrite?
We have to approach this as a question of how, not if. When we do that, we can change computer security.