Comment by notpygame | Hacker News Reader

Comment by notpygame | Hacker News Reader

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? Zero so far. 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.

To quote from a Oct 2020 study on Rust safety - "Our study results reveal that while Rust successfully limits the risks of memory-safety issues in the realm of unsafe code, it also introduces some side effects. In particular, most of the use-after-free and double-free bugs in our data set are related to the automatic drop scheme associated with the ownership-based memory management model." -- "Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs"

They study 60 Rust memory safety vulnerabilities.

As you can see not only does Rust not solve the memory safety problem, it has other issues. Additionally the old research quoted misleads people about the current status of reported memory safety issues in curl.

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 safe code and novel unsafety in unsafe code adds up to as much unsafety as C. The paper's overarching claims aren't quantitative.

I think you're overstating the claims of both the blog post and the study.

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 current research. If you only read this article, you'd be mislead about memory safety in Rust.

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

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

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

Reply on news.ycombinator.com