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

81–90 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#81

Post by rational_indian »

bluGill wrote: post #46
wtallis wrote: post #19

Earlier quoted context omitted.

The main strength of a memory-safe language is that the safety mechanisms are opt-out, not opt-in: you can confine the unsafe behavior to a small, manageable portion of the codebase. And trying to "fix" C to become a memory-safe language would probably just result in something like a Rust dialect that merely bears more superficial resemblance to C. In any case, thorough re-writing of existing codebases would be requi…

I would call C++ a memory safe language that has more than a superficial resemblance to C. Rust makes is more obvious when/where you are intentionally opting out, but most C++ memory bugs are where someone opted out of the modern C++ way to use the C way. (including new/delete as the C way).

> would call C++ a memory safe language

LOL.

Re: Mitigating Memory Safety Issues in Open Source Software

#83

Post by wtallis »

trynton wrote: post #76

"bugs would have been completely prevented by using a memory-safe language" Relying on safe languages isn't going to work as the defect resides in the Memory Management Unit. You would think by now these 'integrated' 'innovators' could come up with a MMU that provides total process isolation.

Have you confused the kind of memory safety that Rust, etc. are about with the Spectre and Meltdown vulnerabilities? Or do you think that each individual array that's potentially subject to a buffer overflow in C should have been allocated by an entirely separate process?

Re: Mitigating Memory Safety Issues in Open Source Software

#84

Post by corebuffer »

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

They removed licensing from their FAQ, but I was able to find this issue: https://github.com/ossf/tac/issues/26

I'm also curious if they will accept GPL or not

Re: Mitigating Memory Safety Issues in Open Source Software

#85

Post by enriquto »

kam wrote: post #82
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

Apache and Curl are not GPL or AGPL to start with.

Of course any such endeavor must have a patina of plausible deniability. That's evildoing 101 :)

Re: Mitigating Memory Safety Issues in Open Source Software

#87

Post by emteycz »

bachmeier wrote: post #74
emteycz wrote: post #52

Earlier quoted context omitted.

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?

A rewrite is not taking it "to the next level". It provides a new version in a new language that does the same things, and if things go according to plan, will have fewer safety issues. There's nothing that binds them to maintain any of these projects. Given Google's history, it's irresponsible to not consider long-term maintenance and other issues.

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.

Re: Mitigating Memory Safety Issues in Open Source Software

#88

Post by lovasoa »

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…

I like cargo because I don't like having to even think about build systems.

I often renounce to contribute to C/C++ projects because I know I will spend more time figuring out how to install all of their dependencies than making my two-line fix.

On the contrary, in the rust ecosystem, I know I can just make my two-line fix, run cargo test, and if there is no red line in the output, I'm done.

> I often hear that it’s because of Cargo

I don't think the main reason is cargo. The main reason is that you don't have to worry that the very simple pointer dereference you just wrote may allow anyone on the internet to take full control of the machine of anyone that runs your software.

Re: Mitigating Memory Safety Issues in Open Source Software

#89

Post by notacoward »

cp9 wrote: post #72
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-…

> There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. there comes a point where we can't let dependencies on Amiga or DEC Alpha (companies/platforms that haven't existed in literal decades) hold the rest of us back. If someone wants to port rust/llvm to those platforms more power to them, but the rest of us don't need to suffer. The only platform that act…

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

Re: Mitigating Memory Safety Issues in Open Source Software

#90

Post by wyldfire »

praptak wrote: post #42
roel_v wrote: post #8

Can someone please fix the title to the original in the blog ('Mitigating Memory Safety Issues in Open Source Software'), because the current title is not at all representative of what the blog is actually saying.

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.

Post reply on HN