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

51–60 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#51

Post by konschubert »

bluGill wrote: post #40
jsty wrote: post #23

Earlier quoted context omitted.

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…

Also it's probably cheaper to fund an OS developer for a year than paying for lunch alone for their own engineers.

Re: Mitigating Memory Safety Issues in Open Source Software

#52

Post by emteycz »

beckman466 wrote: post #37
emteycz wrote: post #21

Earlier quoted context omitted.

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]

They're literally funding an organization that will take software to the next level and share it with the world, what more do you want?

Re: Mitigating Memory Safety Issues in Open Source Software

#53

Post by the_duke »

divs1210 wrote: post #36

Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.

Go, Pony and Haskell all have complex runtimes and a GC, which makes them unsuitable for embedding into other applications or exposing them as widely usable libraries.

Rust, Zig, and to a certain extent D or Nim without GC, can easily expose a C API and have a minimal runtime.

But the others do not provide the same guarantees as (safe) Rust with the borrow checker. All very cool languages in their own right, but memory safety in a no-GC environment is not one of their defining attributes.

Note: a dependency on any of those compilers is still far from trivial for many projects.

Re: Mitigating Memory Safety Issues in Open Source Software

#54

Post by the_af »

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.

> Would not be cheaper to fix those unsafe languages, such as C

I don't think C can be "fixed" without turning it into a radically different language. At that point, why not simply start from scratch?

This is about language design that makes some languages fundamentally unsafe, not about fixing some bugs or hardening the toolset.

Re: Mitigating Memory Safety Issues in Open Source Software

#56

Post by piokoch »

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.

Could be something great, but could end up with some "entity" will rewrite, say, ls or cp and suddenly it will turn out, that ls is still free and open source, but sends all user listed files to that entity (obviously for the sake of the noble purpose of making ls even better and all those stats are anonymous).

And there will be some pro version that does not grab that stats, but you need to purchase subscription.

Re: Mitigating Memory Safety Issues in Open Source Software

#57

Post by choeger »

While rust certainly does a lot of things right, it is still a moving target with a relatively high velocity.

There is a python library that recently switched to rust (partially) and now cannot be build on several platforms.

This also means that very long-lived platforms will probably be forced to upgrade that library every half year or so in line with the development of rust.

I'd say such an initiative needs a long-term supported version of rust, similar to C99 or so.

And this does not even account for cargo. I know you don't have to use cargo, but is that practical?

How are we going to maintain stable software for, say, ten years or more? Do we have anyone committed to providing a stable rust environment for these cases? Especially considering that rust has no ABI for dynamic libraries.

Oh and by the way: We need a way to bootstrap rust as well. The current distribution downloads binaries of the last one to build itself. And it ships with a vendored version of llvm.

So in conclusion: I really like the rust language. But I am concerned that it is still way too immature and to "hip" for long-running, stable projects.

Re: Mitigating Memory Safety Issues in Open Source Software

#59

Post by wizzwizz4 »

choeger wrote: post #57

While rust certainly does a lot of things right, it is still a moving target with a relatively high velocity. There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. This also means that very long-lived platforms will probably be forced to upgrade that library every half year or so in line with the development of rust. I'd say such an initiative needs a long-…

We have a way to bootstrap Rust: https://github.com/thepowersgang/mrustc

Re: Mitigating Memory Safety Issues in Open Source Software

#60

Post by klelatti »

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 example from the ISRG blog [1] directly contradicts the assumption you're making:

> Memory safety vulnerabilities represent one of the biggest threats to Internet security. As such, we at ISRG are interested in finding ways to make the most heavily relied-upon software on the Internet memory safe. Today we’re excited to announce that we’re working with Daniel Stenberg, author of ubiquitous curl software, and WolfSSL, to make critical parts of the curl codebase memory safe.

> ISRG is funding Daniel to work on adding support for Hyper as an HTTP back-end for curl. Hyper is a fast and safe HTTP implementation written in Rust.

I too found the post terse and the lack of quantification of the financial commitment makes me suspicious but I think they deserve the benefit of the doubt for now.

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

Post reply on HN