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

Mitigating Memory Safety Issues in Open Source Software

security.googleblog.com

Post reply on HN
Print view View original

21–30 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#21

Post by emteycz »

Miner49er wrote: post #17
mfer wrote: post #10

Earlier quoted context omitted.

I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.

Your missing what the two parent comments are driving at. Google says that's what it is doing, but this money is going to "an organization" that will seemingly get it's money from Google, giving Google control over whatever open source projects they target.

And? Google can't decide to fund organization that rewrites open source projects, or what? How is that different from forking the projects - apart from Google not taking anything at all?

Re: Mitigating Memory Safety Issues in Open Source Software

#22

Post by cy_hauser »

hypertele-Xii wrote: post #18
stephen82 wrote: post #9

Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.

How do you "fix" C?

Rewrite it in Rust!

Re: Mitigating Memory Safety Issues in Open Source Software

#23

Post by jsty »

enriquto wrote: post #6

semi-conspiracy theory: the main goal of this rewriting is to have less and less infrastructure depending on GPL and AGPL-licensed code

If all Google wanted was GPL- and AGPL-free code, they're quite capable of assigning their own engineers / contractors to work on it rather than the more tortuous route of going via a 3rd party

Re: Mitigating Memory Safety Issues in Open Source Software

#24

Post by Radim »

For what it's worth, I reached out to the Open Source Security Foundation (OpenSSF) after their press release on "Securing Critical Open Source Projects" [0], because my open source project is on their "critical list" (Python top #200) [1].

After some clicking around, I was directed to the OpenSSF mailing list [2].

…where my request was left to rot, without any response.

Made me wonder whether this is just a PR stunt / corporate power grab.

[0] https://opensource.googleblog.com/2020/12/finding-critical-o...

[1] https://news.ycombinator.com/item?id=25381397

[2] https://groups.google.com/g/wg-securing-critical-projects

Re: Mitigating Memory Safety Issues in Open Source Software

#25

Post by K0nserv »

stephen82 wrote: post #9

Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.

I don't know how well that would work. For example, my understanding of Rust's bounding checking for slice indexing is that often the compiler can prove it's not needed and the check is optimised out because of the type system. This woulnd't work in C because of C's lacking type system

Re: Mitigating Memory Safety Issues in Open Source Software

#27

Post by gnfargbl »

lrossi wrote: post #3

What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools. Correct me if I’m wrong, but that’s my understanding of the rather terse article. I would rather have the original maintainers funded and still in control of the many pieces that form the basis of the major Linux distribut…

The article says that Google is committing funding to the ISRG (https://abetterinternet.org). It isn't really clear whether that is one-off funding, or the start of an ongoing relationship.

The ISRG seems to have two projects of this type mentioned on its website: an improvement to curl (https://www.abetterinternet.org/post/memory-safe-curl/), in which the ISRG funded the curl author directly; and an improvement to httpd (https://www.abetterinternet.org/post/memory-safe-tls-apache/), in which Google (via the ISRG) are funding an httpd committer.

Re: Mitigating Memory Safety Issues in Open Source Software

#28

Post by flohofwoe »

mfer wrote: post #10
flohofwoe wrote: post #4

Earlier quoted context omitted.

Yeah, it sounds a lot like Google is going to "hijack" popular open source projects for the sake of "security". It'll be interesting to watch how this plays out. But I pity the projects where Google's gaze falls upon.

I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.

If such changes had been planned in the project all along and the money injection can help speeding this process up that's fine. But I can't see Google security people getting involved being a good thing otherwise. They come across as prioritising security problems over anything else (e.g. "if all you have is a hammer...") and I'd be surprised if this sort of extremism will be healthy for a project in the long run. Memory safety is just one of many aspects to juggle in a software project.

Re: Mitigating Memory Safety Issues in Open Source Software

#29

Post by folex »

lrossi wrote: post #3

What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools. Correct me if I’m wrong, but that’s my understanding of the rather terse article. I would rather have the original maintainers funded and still in control of the many pieces that form the basis of the major Linux distribut…

> The ISRG's approach of working directly with maintainers to support rewriting tools and libraries incrementally falls directly in line with our perspective here at Google.

Incrementally – that means in-place. You can't fork and rewrite incrementally since there will be no adoption/users of the fork.

Also they talk about maintainers of the projects. I think that largely means original authors and maintainers, not forks.

I don't see how you come to that conclusion. Could you clarify? Thanks :)

Re: Mitigating Memory Safety Issues in Open Source Software

#30

Post by jedisct1 »

hypertele-Xii wrote: post #18
stephen82 wrote: post #9

Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.

How do you "fix" C?

Zig is a “fixed” version of C.
Post reply on HN