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

161–170 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#161

Post by jaas »

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…

(Executive Director of ISRG here)

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

This's not what's happening. Here's what is:

ISRG plans and coordinates investments in moving open source software to memory safe languages. We have a strong preference for working on these plans with maintainers and developers, and then funding them to execute the plan.

Once we have a plan prepared, and, ideally, maintainers/developers on board, then we pitch it for funding. Once someone (e.g. Google) funds the project, then ISRG handles contracts with the project developers/maintainers to get the work done. In some cases maintainers may be on board but want us to find a contractor to actually do the work.

In both of the first two projects, and in most future cases, the money that Google (or another company) provides will largely go to project maintainers / developers.

Re: Mitigating Memory Safety Issues in Open Source Software

#162

Post by Arch-TK »

tediousdemise wrote: post #63

Is there a reason why some developers prefer Rust over C++? I often hear that it’s because of Cargo, but in my experience, universal build systems and package managers end up not really solving the problem they are designed to solve, and are a huge attack vector. Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. C++, on the other hand, has a variety of choices for build sy…

At this point if you stick to a limited subset of C++ and don't go too deep you can get a perfectly safe language which is powerful and performant.

If you want a safer language with in my opinion a far better type system than anything Rust could possibly achieve at this point you can use Ada.

But why not those two options? Old, smelly and most importantly, difficult to deal with dependencies. You have to actually think about how your API will work in your library because if your library ever ends up used anywhere people are going to be running different versions and you don't want to ruin their day by having them change their code every time they update their machine.

In comes cargo (and friends, lots of other languages have picked up the same idea) where everything is managed by the programming language's choice of build system and API stability and dealing with dependency hell no longer exists when you statically link everything.

I think people don't care or want to care about why we got to where we are (distributions with dependencies and API stability and an aversion to micro-modules). A lot of people just want things to work when you run one command no matter how much complexity gets hidden under the carpet, how obscure the issues end up being and how windows-esque the debugging process ends up being when things do go wrong.

All this pushed by lots of big companies who don't care about the origins of the open source model and how distributions do things and instead only care about lining their own pockets.

Mark my words, distributions will disappear in a few year's time, people will cheer this on as some great technological advancement, things like snap will become the de-facto standard and debugging a complex problem will just never happen again. The internet will become filled with forum posts of how people "fixed" a problem by rebooting their machine or deleting a random file or re-installing.

Anyway, maybe I'm just a crazy person thinking up crazy scenarios and being irrationally scared of "progress".

Re: Mitigating Memory Safety Issues in Open Source Software

#163

Post by rcxdude »

tediousdemise wrote: post #63

Is there a reason why some developers prefer Rust over C++? I often hear that it’s because of Cargo, but in my experience, universal build systems and package managers end up not really solving the problem they are designed to solve, and are a huge attack vector. Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. C++, on the other hand, has a variety of choices for build sy…

C++'s build systems are miserable. Almost any other language is preferable (yes, even a complex maven project). CMake and co are just as susceptable to issues when you want to do something off the beaten path, and have a few landmines on the beaten path just to spice it up. Cargo is a breath of fresh air in comparison (and as package managers go it's very good: they took some care to learn from the mistakes of others from the get-go). And rust isn't wedded to cargo: you can build your code using make if you wish. In fact rustc doesn't use cargo.

Re: Mitigating Memory Safety Issues in Open Source Software

#164

Post by jaas »

lrossi wrote: post #118
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…

Replying to myself as I cannot edit anymore. As others pointed out, it’s not clear who will do the rewrites. Based on the curl example, it might be the maintainers. It would have been great if they could state that concretely. I’m also wondering why there’s a middle man instead of funding the projects directly, but that’s another story.

I'm the head of ISRG, the "middle man" entity you're referring to.

We have a memory safety initiative in which we plan and fund projects to move popular open source software to memory safe languages. For each plan we make we seek a funder - in a couple of cases now that has been Google, but it may be others in the future.

We are in the "middle" of the financing in the sense that funding passes through us, but the memory safety initiative is coordinated primarily by us. We select projects and work with maintainers to make plans. Part of that coordination we perform is matching up projects with funders like Google, and then managing the contracts and overseeing the work to completion.

Re: Mitigating Memory Safety Issues in Open Source Software

#165

Post by jaas »

wyldfire wrote: post #90
praptak wrote: post #42

Earlier quoted context omitted.

Also "for rewriting popular systems in Rust" is just false. The blog is about improving memory safety and gives two pieces of software rewritten in Rust as an example. There's nothing about this effort being focused on rewriting things in Rust.

Are you sure? > That’s why we’re expanding our collaboration with the Internet Security Research Group to support the reimplementation of critical open-source software in memory-safe languages. Though the rest of the article doesn't go into detail about this effort beyond http/TLS libs for curl.

Rust is going to be used often, but we are open to other choices when they make sense.

Since most unsafe code is C or C++, Rust usually makes the most sense for rewriting one component at a time. It integrates with C and C++ very cleanly because it has good FFI and no runtime.

If we were rewriting more projects from scratch and integration with existing C and C++ code was not important, we might use other languages more often. I don't expect we'll attempt to rewrite many pieces of software from scratch.

Source: I run the memory safety initiative at ISRG.

Re: Mitigating Memory Safety Issues in Open Source Software

#166

Post by rcxdude »

bluGill wrote: post #102
madmoose wrote: post #65

Earlier quoted context omitted.

> I would call C++ a memory safe language C++ is not, in any sense, a memory safe language.

Then you don't know anything about C++, only the C legacy it is built on. Modern C++ has good data structures and good memory management. To be fair actually using those features of C++ instead of the C legacy is still catching on. Most instructors aren't even teaching it. Using C in C++ is like using unsafe everywhere in rust - you can do it, but you lose all the advantages.

This is a common viewpoint but also wrong. There's plenty of ways to invoke memory unsafety in 'modern' C++: iterator invalidation is probably the biggest source.

Re: Mitigating Memory Safety Issues in Open Source Software

#167

Post by rcxdude »

stephen82 wrote: post #67
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 based my comment on Jens Gustedt's article [1] about adding a "defer" mechanism in standard C. Clearly, the C committee works hard on improving the language and they are in the process to standardize important features, such as lambda functions, auto, typeof (like C++'s decltype more or less), and so forth. In my humble opinion, "defer" can mild the buffer / memory overflow, but of course not permanently remedied i…

Defer doesn't even replace destructors, let alone resolve memory safety in C.

Re: Mitigating Memory Safety Issues in Open Source Software

#168

Post by jaas »

Executive Director of ISRG here. To provides some more clarity on how this partnership works...

ISRG plans and coordinates investments in moving open source software to memory safe languages. We have a strong preference for working on these plans with maintainers and developers, and then funding them to execute the plan.

Once we have a plan prepared, and, ideally, maintainers/developers on board, then we pitch it for funding. Once someone (e.g. Google) funds the project, then ISRG handles contracts with the project developers/maintainers to get the work done. In some cases maintainers may be on board but want us to find a contractor to actually do the work.

In both of the first two projects, and in most future cases, the money that Google (or another company) provides will largely go to project maintainers / developers.

Re: Mitigating Memory Safety Issues in Open Source Software

#169

Post by cycloptic »

gordian-mind wrote: post #121
emteycz wrote: post #87

Earlier quoted context omitted.

No, C and Rust definitely don't do the same things. If the project is open source, I don't see how any maintenance concerns are relevant - everybody can judge for themselves.

It's not that smart to mistake the purpose or specification of a program, with its implementation. Anyway, if everybody can judge for themselves, then I guess it's cool to judge that giving Google an inch over many critical open source projects is a horrible idea.

You speak as if it's impossible for someone outside Google to maintain a project that isn't written in C++ or C...

Re: Mitigating Memory Safety Issues in Open Source Software

#170

Post by tptacek »

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.

You're scare-quoting "an organization", which suggests you don't know what the ISRG is. You might look them up. They're pretty well-liked.
Post reply on HN