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

181–190 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#181

Post by oscargrouch »

praptak wrote: post #140
wyldfire wrote: post #90

Earlier quoted context omitted.

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.

The "memory-safe languages" may mean Go, Java and a bunch of other less popular languages.

In the end of the day only Rust will be chosen because we are talking mostly about system infrastructure.

Re: Mitigating Memory Safety Issues in Open Source Software

#182

Post by DrBazza »

KenanSulayman wrote: post #148
DrBazza wrote: post #2

It's buried in there, but it doesn't specifically say Rust: > 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.

> The new Rust-based HTTP and TLS backends for curl and now this new TLS library for Apache httpd are an important starting point in this overall effort.

This item had a different title specifically mentioning rust which had been changed to remove it, before you made your comment

Re: Mitigating Memory Safety Issues in Open Source Software

#183

Post by lrossi »

jaas wrote: post #161
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 th…

This sounds great, thanks for clarifying!

Also, thanks for Let’s Encrypt. I didn’t make the connection between the two names. This initiative looks much better to me now.

Is rust the only language that you are considering? Would go make sense as well?

Re: Mitigating Memory Safety Issues in Open Source Software

#184

Post by blt »

Tobu wrote: post #153
mariusor wrote: post #100

Earlier quoted context omitted.

A big chunk of the C++ development is done in game studios. I doubt they would be willing to move away from it just for memory safety's sake.

Buggy AAA releases are currently the norm, but that takes a reputational and financial toll and doesn't make for happy developers either. Cyberpunk 2077 is the latest example.

But aren't most user-visible bugs in games caused by logic errors, not memory errors?

Re: Mitigating Memory Safety Issues in Open Source Software

#185

Post by saagarjha »

bowyakka wrote: post #134
notacoward wrote: post #89

Earlier quoted context omitted.

> dependencies on Amiga or DEC Alpha What about embedded platforms, which tend to remain relevant (i.e. present in large numbers out in the real world) much longer than desktop or server platforms? Don't they matter? Don't they need updates, including for security, as much as any other?

Is it not a bit of a paradox that said embedded platforms matter enormously right up to, but not including the point of having toolchains ported to them and maintained? And yes while gcc can be built to produce binaries for an alpha it's not producing any bugs right?

The interests of people writing new language toolchains sadly does not seem to extend to supporting older platforms. This doesn't mean that they are not important, it just means that that they are not important to the people writing the new language toolchains.

Re: Mitigating Memory Safety Issues in Open Source Software

#186

Post by saagarjha »

tptacek wrote: post #177
saagarjha wrote: post #176

Earlier quoted context omitted.

There's a ton of platforms that Rust doesn't not target, or targets but without many guarantees of support. The can be problematic as its closest competitors (C++, but especially C) generally have much more widespread support.

That's a problem, but it's one that's more likely to be worked around (most likely: by maintaining unsafe forks for those platforms) than "creating entire new communities of support for another language" or "redesigning whole projects to make GC tenable". I think you might see some full-system rewrites for serverside components where Go will work out. But I think the projects we're talking about, like I said, have en…

Oh, I'm not suggesting that they will use Go–they will use C and I'm just responding to you saying that it is difficult to find situations where Rust is unworkable.

Re: Mitigating Memory Safety Issues in Open Source Software

#187

Post by [deleted] »

kbenson wrote: post #152
bobcallme wrote: post #150

The more pressing issue is the fact that critical tools that we depend upon are not properly funded or the incentive to properly maintain them is simply not there. Many of these projects were started as pet projects in peoples spare time. Sure, Google gives a lot of money and contributes to some of these projects but their contributions do not match how much they depend upon them. This is all compounded by the fact t…

> In the case of Rust, I am tired of people evangelizing it when it's plagued with issues that undermine its goals Do you mind explaining what you mean here? You seem to be alluding to something different than an unstable toolchain which you mention after.

[deleted]

Re: Mitigating Memory Safety Issues in Open Source Software

#188

Post by damnyou »

notpygame wrote: post #75

The security information about C and curl is a bit outdated in the post, and recent research shows Rust does not solve the memory safety issue. The "recent study" quoted in the article was published at the beginning of 2019, using older data. Current vulnerability data shows that curl has very much limited the risk of memory safety issues. How many reported security vulnerabilities in the last two releases of curl? Z…

Safe Rust solves the problem of memory safety (assuming that any unsafe code is correct). Unsafe Rust continues to be potentially memory unsafe. That is equivalent to other memory safe languages like Java (which is memory safe under the assumption that the JVM has no memory safety bugs and any JNI code is correct), and a very large improvement over C and C++.

Re: Mitigating Memory Safety Issues in Open Source Software

#189

Post by duckerude »

notpygame wrote: post #180
duckerude wrote: post #119

Earlier quoted context omitted.

Rust does not solve the memory safety issue. It does mitigate it, and the post is about mitigation. That study finds that Rust "successfully limits memory-safety risks to the realm of unsafe code". It also finds that Rust has novel patterns of unsafety in unsafe code. That's important! But it's fully compatible with the claim that Rust is much safer than C overall. I don't think it ever says that the sum of safety in…

The recent track record of curl shows it has zero reported memory safety issues recently. Reading the article and the old linked research you'd be mislead. It also states that Rust completely prevents them - it does not. The article talks about mitigation, but also says: "would have been completely prevented by using a memory-safe language". The "completely prevented" claim in the article is the one not supported by…

> The recent track record of curl shows it has zero reported memory safety issues recently.

Only if you look very recently. Earlier you said:

> You have to go back 9 months before you find one expired-pointer derefence issue resulting in potential data being sent to the wrong connection in rare circumstances and configurations. Which is a logic error that could happen in Rust too.

That bug is 6 months old and could not happen in safe Rust because references (pointers) cannot outlive their referents.

> It also states that Rust completely prevents them - it does not. The article talks about mitigation, but also says: "would have been completely prevented by using a memory-safe language".

It is literally true that they "would have been completely prevented by using a memory-safe language." The complication is that Rust is only memory-safe if you don't use unsafe.

rustls (the new curl component in question) uses no unsafe itself. I find some unsafe in its dependencies, but most of it seems to be for FFI, which is inherently unsafe. I'm also not sure that those should count—do OpenSSL vulnerabilities count as libcurl vulnerabilities?

> The "completely prevented" claim in the article is the one not supported by current research.

I will grant you that it's slightly misleading because it's possible to write unsafe Rust code. But that's not news, "current research" has nothing to do with it.

Re: Mitigating Memory Safety Issues in Open Source Software

#190

Post by damnyou »

notpygame wrote: post #180
duckerude wrote: post #119

Earlier quoted context omitted.

Rust does not solve the memory safety issue. It does mitigate it, and the post is about mitigation. That study finds that Rust "successfully limits memory-safety risks to the realm of unsafe code". It also finds that Rust has novel patterns of unsafety in unsafe code. That's important! But it's fully compatible with the claim that Rust is much safer than C overall. I don't think it ever says that the sum of safety in…

The recent track record of curl shows it has zero reported memory safety issues recently. Reading the article and the old linked research you'd be mislead. It also states that Rust completely prevents them - it does not. The article talks about mitigation, but also says: "would have been completely prevented by using a memory-safe language". The "completely prevented" claim in the article is the one not supported by…

No memory safe language in existence can meet your standards, since they're all written on a bedrock of unsafe code.
Post reply on HN