Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fish in a Barrel Memory Safety Bounty Program

github.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Fish in a Barrel Memory Safety Bounty Program

#11

Post by saagarjha »

kingkilr wrote: post #9
stevekemp wrote: post #8

Earlier quoted context omitted.

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/graphic…

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

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.

Re: Fish in a Barrel Memory Safety Bounty Program

#12

Post by reaperhulk »

Arnavion wrote: post #6
hackcasual wrote: post #3

> 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 pr…

>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 Ru…

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.

Re: Fish in a Barrel Memory Safety Bounty Program

#13

Post by saagarjha »

hackcasual wrote: post #3

> 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 pr…

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.

Re: Fish in a Barrel Memory Safety Bounty Program

#14

Post by kingkilr »

saagarjha wrote: post #11
kingkilr wrote: post #9

Earlier quoted context omitted.

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

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.

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.

Re: Fish in a Barrel Memory Safety Bounty Program

#15

Post by 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.

Re: Fish in a Barrel Memory Safety Bounty Program

#16

Post by kingkilr »

f00zz wrote: post #15

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.

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!

Re: Fish in a Barrel Memory Safety Bounty Program

#18

Post by Arnavion »

reaperhulk wrote: post #12
Arnavion wrote: post #6

Earlier quoted context omitted.

>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 Ru…

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…

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

Re: Fish in a Barrel Memory Safety Bounty Program

#19

Post by ploxiln »

f00zz wrote: post #15

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.

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

Re: Fish in a Barrel Memory Safety Bounty Program

#20

Post by tialaramex »

ploxiln wrote: post #19
f00zz wrote: post #15

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.

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

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.
Post reply on HN