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

21–25 of 25 posts

Re: Fish in a Barrel Memory Safety Bounty Program

#21

Post by NullPrefix »

tialaramex wrote: post #20
ploxiln wrote: post #19

Earlier quoted context omitted.

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.

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

Re: Fish in a Barrel Memory Safety Bounty Program

#22

Post by tialaramex »

NullPrefix wrote: post #21
tialaramex wrote: post #20

Earlier quoted context omitted.

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.

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

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?

Re: Fish in a Barrel Memory Safety Bounty Program

#23

Post by stevekemp »

philipkglass wrote: post #10
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…

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.

Bad examples, yes. Sorry!

Pretend I wrote gstreamer, wireshark, or similar.

Re: Fish in a Barrel Memory Safety Bounty Program

#24

Post by imtringued »

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.

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.

Re: Fish in a Barrel Memory Safety Bounty Program

#25

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

Post reply on HN