
Fish in a Barrel Memory Safety Bounty Program - Titanous
https://github.com/fishinabarrel/bounty
======
f00zz
Sorry, but I'm not seeing how this will help. If I take e.g. libpng and
rewrite it in Rust, then it's basically a new project. I don't understand how
a patch replacing all existing code will be accepted upstream, or how the many
projects using libpng will be convinced to use my new library.

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

[https://gitlab.gnome.org/GNOME/librsvg](https://gitlab.gnome.org/GNOME/librsvg)
[https://people.gnome.org/~federico/news-2016-10.html](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.)

~~~
tialaramex
But the vastly many more _users_ don't need that compiler right? If you merely
write a program to render SVG you don't care, your program just got safer
"magically" ? If you run such a program you aren't even aware anything
happened, the updated version is apparently safer.

~~~
NullPrefix
Except for all the corner cases that were covered by the original and are not
by the rewrite.

~~~
tialaramex
The librsvg author doesn't list any such corner cases.

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?

------
kingkilr
One of the folks behind the bounty here. Happy to answer questions.

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

------
hackcasual
> Q: What if the maintainers won't accept the patch?

> 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

~~~
Arnavion
>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...](https://www.postgresql.org/message-
id/CAASwCXdQUiuUnhycdRvrUmHuzk5PsaGxr54U4t34teQjcjb%3DAQ%40mail.gmail.com)

~~~
reaperhulk
Making more things accessible via memory safe languages allows people to more
easily transition to those memory safe languages even if they have
dependencies that are not themselves memory safe. Boiling the ocean is
impractical and memory safety is not all or nothing, so we're interested in
encouraging people to find ways to migrate larger and larger pieces.

That said, we will consider level of effort as a component of our judging
process when determining eligibility and bounty size.

~~~
Arnavion
>That said, we will consider level of effort as a component of our judging
process when determining eligibility and bounty size.

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
_un_ send the PR / patch in the maintainer's mailbox.

------
rurban
Rewriting stuff in memory safe languages would be a worthwhile goal, but then
they go on by providing bounties to write Linux Kernel drivers in Rust.

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...](https://github.com/rust-
lang/rust/issues?q=is%3Aissue+is%3Aopen+stack+overflow) 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](https://doc.rust-
lang.org/reference/unsafe-blocks.html)

3\. Races as eg with [https://doc.rust-lang.org/reference/items/static-
items.html?...](https://doc.rust-lang.org/reference/items/static-
items.html?highlight=Concurrency#mutable-statics) requiring manual mutexes

