Fish in a Barrel Memory Safety Bounty Program
1–10 of 25 posts
Re: Fish in a Barrel Memory Safety Bounty Program
#2One of the folks behind the bounty here. Happy to answer questions.
Re: Fish in a Barrel Memory Safety Bounty Program
#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 project to accept a patch that at the very least requires changes to the project build system
Re: Fish in a Barrel Memory Safety Bounty Program
#4> 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…
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.
Re: Fish in a Barrel Memory Safety Bounty Program
#5> 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…
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.
Re: Fish in a Barrel Memory Safety Bounty Program
#6> 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 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...
Re: Fish in a Barrel Memory Safety Bounty Program
#7> 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…
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.
Maybe make it a requirement that the contribution PR / email has to mention https://github.com/fishinabarrel/bounty so that maintainers know who to give feedback to.
Re: Fish in a Barrel Memory Safety Bounty Program
#8One of the folks behind the bounty here. Happy to answer questions.
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.)
Re: Fish in a Barrel Memory Safety Bounty Program
#9One of the folks behind the bounty here. Happy to answer questions.
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!
Re: Fish in a Barrel Memory Safety Bounty Program
#10One of the folks behind the bounty here. Happy to answer questions.
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…
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.