Live data from Hacker News

Mitigating Memory Safety Issues in Open Source Software

security.googleblog.com

201–210 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#201

Earlier quoted context omitted.

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.

While you are technically correct, those who study C++ security note that those are a tiny minority of all security errors. Still an issue, but not nearly as common an issue as the ones that come from the C roots of C++.

Re: Mitigating Memory Safety Issues in Open Source Software

#202

Earlier quoted context omitted.

Or Ada or Wuffs But I have always used Pascal for that. It has memory safe strings and arrays with refcounting, so long as one avoids using other features like pointers, classes, inline assembly, it is perfect.

Wuffs? Never heard of that one before. Edit: here's the link, interesting idea. https://github.com/google/wuffs

And it is supposed to be safer than a language that is only memory-safe

The memory-safe languages can still panic or have integer overflows, Wuffs should prevent even that

Re: Mitigating Memory Safety Issues in Open Source Software

#203

Earlier quoted context omitted.

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.

While you are technically correct, those who study C++ security note that those are a tiny minority of all security errors. Still an issue, but not nearly as common an issue as the ones that come from the C roots of C++.

No true Scotsman huh?

https://en.wikipedia.org/wiki/No_true_Scotsman

Also can you link to an example of this purported memory safe C++ compiler? Please note for an apples to apples comparison it must reject all memory unsafe non-modern C++ constructs.

Re: Mitigating Memory Safety Issues in Open Source Software

#204
post #199
post #126

A worthwhile goal. But not in a memory unsafe language, please. There's hype and there are lies: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

This is flamebait, ignoring that "nearly perfect detection" and "no detection whatsoever" are very different things. But also, stack overflows aren't memory unsafe in modern rust. The issue search you want to find memory safety issues is: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

No flame sit. It is either safe or not. Safer doesn't qualify as safe.

Your query searches for type unsafeties. A third query would be for concurrency unsafety: deadlock. All three unsafeties are builtin by design. There's no way to deny it. But they still do repeat the same lies again and again.

Stack overflows being memory safe you can tell your grandma or upper management. Problem was rust was once memory safe, but they ripped out the GC. Now it's just better than C++, but not better than Java or really safe languages. Overhype rarely reflects well on a community.

Re: Mitigating Memory Safety Issues in Open Source Software

#205
post #40

Earlier quoted context omitted.

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…

What kinds of tax breaks are available for the case of using consultants instead of employees?

It isn't consultants it is 501 charities doing the work. The charity hires the consultants.

There are a lot of tricks needed to make the above work, and details that you need to consult a lawyer and accountant for.

Re: Mitigating Memory Safety Issues in Open Source Software

#206
post #10

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.

If they pay for the rewrite, they have control over it.

Re: Mitigating Memory Safety Issues in Open Source Software

#208

Earlier quoted context omitted.

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.

It's not a matter of interest; if an embedded platform matters they should be willing to pay someone to port Rust.

Re: Mitigating Memory Safety Issues in Open Source Software

#209

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 memo…

D now has a prototype borrow checker implemented.

Re: Mitigating Memory Safety Issues in Open Source Software

#210
post #208

Earlier quoted context omitted.

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.

It's not a matter of interest; if an embedded platform matters they should be willing to pay someone to port Rust.

…or they can just continue using C.
Post reply on HN