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

31–40 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#31

Post by raverbashing »

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.

You can't fix what is fundamentally broken.

In the same idea of "Any sufficiently complicated C program contains an ad hoc, bug-ridden, slow implementation of half of Common Lisp." let's paraphrase

Any sufficiently safe C program contains an ad-hoc (etc.) implementation of the infrastructure needed to make it safe:

- custom string implementation

- custom object/memory management

- custom memory slices and other data structures

Not forgetting the compiler tricks added to try and catch when the program does something stupid

Re: Mitigating Memory Safety Issues in Open Source Software

#32

Post by encom »

mempko wrote: post #16
nojito wrote: post #13

Earlier quoted context omitted.

Most of those project authors refuse to rewrite or adopt memory safe languages in their projects.

Any why shouldn't they?

I don't know, reinventing the wheel with the latest buzzword compliant language sounds like a fun time. Think of all the exciting new bugs you get to fix!

Re: Mitigating Memory Safety Issues in Open Source Software

#34

Post by the_duke »

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…

At least for curl the project leadership is closely involved, as evidenced by a related article on Stenbergs blog [1] and the ISRG annoucement [2], which mentions funding Stenberg directly and is actually linked from this anouncement...

Please don't make statements like that without doing a minimal amount of effort to verify.

[1] https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...

[2] https://www.abetterinternet.org/post/memory-safe-curl/

Re: Mitigating Memory Safety Issues in Open Source Software

#35

Post by pyb »

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.

-

Re: Mitigating Memory Safety Issues in Open Source Software

#37

Post by beckman466 »

emteycz wrote: post #21
Miner49er wrote: post #17

Earlier quoted context omitted.

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?

[flagged]

Re: Mitigating Memory Safety Issues in Open Source Software

#40

Post by bluGill »

jsty wrote: post #23
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

Their accountants probably prefer this route though. They don't get a competitive advantage by have a proprietary license, so open source is a good choice, but the GPL has issues they want to avoid. By going this route they can use tax breaks that are not available for doing the work in house. Sure it is more complex, but the results matter, and the result they are hoping for is someone else does work that they don't pay for.
Post reply on HN