Mitigating Memory Safety Issues in Open Source Software • Hacker News Board

Re: Mitigating Memory Safety Issues in Open Source Software

#231

Post by tdimitrov » Fri, Feb 19, 2021, 9:39 AM UTC

galgalesh wrote: post #172

tdimitrov wrote: post #58

Rust is a nice language for greenfield system software project. But everyone in the software industry knows that you can't just put a project on hold and rewrite completely in new language. I can't see anything good coming from this initiative.

Rust is designed to integrate into legacy codebases so security critical code can be rewritten in small steps. See the URL parser I Firefox. Moreover, the initiative this post is talking about uses rust to rewrite small parts of a C codebase. Honestly, I'm getting more and more disappointed by the quality of discussion here on HN.

Thanks for the kind words :)

There is no such thing as security critical code. If it is out there - it can be expoloited. There are a lot of stories with minor exploit chaining leading to huge compromise.

Re: Mitigating Memory Safety Issues in Open Source Software

#232

Post by Miner49er » Fri, Feb 19, 2021, 1:10 PM UTC

tptacek wrote: post #170

Miner49er wrote: post #17

Earlier quoted context omitted.

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.

I was quoting OP.

Re: Mitigating Memory Safety Issues in Open Source Software

#233

Post by Arch-TK » Fri, Feb 19, 2021, 1:11 PM UTC

c-cube wrote: post #200

Arch-TK wrote: post #162

Earlier quoted context omitted.

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

Is Ada memory safe in the presence of malloc/free?

Here is a good summary of how Ada deals with safety in the context of memory management: https://news.ycombinator.com/item?id=14216128

It's not rust but at the same time I think rust has sacrificed general safety in favor of memory safety which has produced a tendency towards a false sense of security.

After all, it seems rust still has memory safety issues despite the borrow checker: https://arxiv.org/pdf/2003.03296.pdf

Re: Mitigating Memory Safety Issues in Open Source Software

#234

Post by oreally » Fri, Feb 19, 2021, 1:33 PM UTC

jaas wrote: post #168

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…

Have you considered the downsides of this shift? For example c++, with these initiatives I'm thoroughly expecting the compile times to bloat up along with increasingly bloated code in the effort to make the code safer.

Re: Mitigating Memory Safety Issues in Open Source Software

#235

Post by tptacek » Fri, Feb 19, 2021, 4:31 PM UTC

pjmlp wrote: post #229

tptacek wrote: post #228

Earlier quoted context omitted.

Yeah none of that is going to happen. People aren't going to rewrite major open source projects in Oberon, or specially hosted .NET, or custom JVMs, or Ada. ISRG isn't going to arrange funding for things to be rewritten in another memory-unsafe language, so C++ is right out. Stuff is going to get rewritten in Rust. Sorry! That sounds snarky, I know. I promise, I'm not being snarky, and, again: it ain't my first choic…

In what concerns Microsoft, the official security guidelines are .NET, Rust and C++ (with Core Guidelines). As for the other platforms, and what Google is paying for, lets see where the bribe drives people into, after all from your point of view Google should rewrite gVisor and everything k8s as well.

No, I don't see how you get there from what I said.

Re: Mitigating Memory Safety Issues in Open Source Software

#236

Post by pjmlp » Fri, Feb 19, 2021, 6:43 PM UTC

tptacek wrote: post #235

pjmlp wrote: post #229

Earlier quoted context omitted.

In what concerns Microsoft, the official security guidelines are .NET, Rust and C++ (with Core Guidelines). As for the other platforms, and what Google is paying for, lets see where the bribe drives people into, after all from your point of view Google should rewrite gVisor and everything k8s as well.

No, I don't see how you get there from what I said.

> Stuff is going to get rewritten in Rust.

Yes it definitely will, but not only, specially among groups where not using a GC is more of a religious issue than an actual technical impediment.

Re: Mitigating Memory Safety Issues in Open Source Software

#237

Post by tptacek » Fri, Feb 19, 2021, 7:22 PM UTC

pjmlp wrote: post #236

tptacek wrote: post #235

Earlier quoted context omitted.

No, I don't see how you get there from what I said.

> Stuff is going to get rewritten in Rust. Yes it definitely will, but not only, specially among groups where not using a GC is more of a religious issue than an actual technical impediment.

I'm not making a value judgement. I prefer GC'd languages. I'm saying: if they're not GC'd now, when there are multiple excellent choices for managed-runtime languages, it ain't gonna be GC'd. And obviously, it's not going to be C++.

Re: Mitigating Memory Safety Issues in Open Source Software

#238

Post by adamnemecek » Fri, Feb 19, 2021, 8:20 PM UTC

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

At some point, they had to switch from Python 2 to Python 3 no?

Re: Mitigating Memory Safety Issues in Open Source Software

#239

Post by pjmlp » Sat, Feb 20, 2021, 11:38 AM UTC

tptacek wrote: post #237

pjmlp wrote: post #236

Earlier quoted context omitted.

> Stuff is going to get rewritten in Rust. Yes it definitely will, but not only, specially among groups where not using a GC is more of a religious issue than an actual technical impediment.

I'm not making a value judgement. I prefer GC'd languages. I'm saying: if they're not GC'd now, when there are multiple excellent choices for managed-runtime languages, it ain't gonna be GC'd. And obviously, it's not going to be C++.

Ok there I agree with you, however in some domains the choice is made by who is calling the shots and not due the technical merits of some sorts.

Windows is a good example of this politics game actually.

Joe Duffy mentioned on his Rustconf keynote that even with the system running in production, the Windows team couldn't be argued against.

A system that even powered parts of Asian Bing infrastructure.

Likewise they clearly sabotaged the Longhorn efforts, to replace them with COM, and yet UWP, mostly written in C++, happens to usually run slower than traditional .NET applications on Win32, or any other compiled GC'd language on Windows for that matter.

Re: Mitigating Memory Safety Issues in Open Source Software

#240

Post by lzutao » Sat, Feb 20, 2021, 12:49 PM UTC

nimmer wrote: post #198

floatboth wrote: post #103

Earlier quoted context omitted.

From [1]: > ORC is Nim’s all-new cycle collector based on ARC. It can be considered a full-blown GC since it includes a local tracing phase (contrary to most other tracing GCs which do global tracing). ORC is what you should use when working with Nim’s async because it contains cycles that need to be dealt with. Sooooo unless you > disable the GC and do manual memory management, but then you lose access to most of th…

No. It's an inlined reference counter, not a runtime with dedicated thread and so on. Most people use "GC" to refer to the latter.

like swift you say