News for hackers. Stuff that matters.
Re:Mitigating Memory Safety Issues in Open Source Software by tptacek on Thursday February 18, 2021 @02:11PM (#26184131)
You're going to see a lot of Rust, because by and large the programs ISRG and Google are talking about remain in memory-unsafe languages because they have constituencies where dynamic-runtime memory-safe languages are problematic. That's why security people are so excited about Rust: it's hard to come up with modern settings where Rust is unworkable, unlike Go (a language I prefer to Rust), which, for instance, isn't a good fit for the Linux kernel or for the guts of Chromium.
Re:Mitigating Memory Safety Issues in Open Source Software by saagarjha on Thursday February 18, 2021 @02:28PM (#26184326)
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.
Re:Mitigating Memory Safety Issues in Open Source Software by tptacek on Thursday February 18, 2021 @02:38PM (#26184435)
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 ended up in this position mostly because they can't easily be written in Go, or they already would have been (if only be a competitor).

Re:Mitigating Memory Safety Issues in Open Source Software by saagarjha on Thursday February 18, 2021 @03:02PM (#26184691)
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 by tptacek on Thursday February 18, 2021 @03:25PM (#26185001)
The premise of this story is that ISRG is going to secure funding to essentially bribe people (my words, and I think it's a very good project) to not keep critical software in C anymore.

My guess is what will happen in the cases where Rust is unworkable is that there will be less-secure forks for the obscure platforms.

Re:Mitigating Memory Safety Issues in Open Source Software by pjmlp on Friday February 19, 2021 @01:42AM (#26190407)
Rust is not the only option.

F-Secure has been using TamaGo for bare metal on their secure USB keys.

MeadowLabs is using .NET with a tiny C++ hardware glue for IoT.

Aicas and PTC are still in business delivering real time bare metal Java stacks.

Astrobe is still in business selling Oberon compilers for embedded development.

MikroElektronika is still in business selling Pascal and Basic compilers for embedded development.

And then there are those 5 surviving Ada compiler vendors, one of them open source.

Finally, if there is no way around having to use C, there is no reason not to use C++ instead other that anti-C++ hater religion.

Unless we are talking about UNIX clones, thanks to them C will still be around for several decades to come anyway.

Re:Mitigating Memory Safety Issues in Open Source Software by tptacek on Friday February 19, 2021 @02:51AM (#26190672)
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 choice (it'll be fine though).

Re:Mitigating Memory Safety Issues in Open Source Software by pjmlp on Friday February 19, 2021 @03:34AM (#26190891)
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.

Re:Mitigating Memory Safety Issues in Open Source Software by tptacek on Friday February 19, 2021 @11:31AM (#26194816)
No, I don't see how you get there from what I said.
Re:Mitigating Memory Safety Issues in Open Source Software by pjmlp on Friday February 19, 2021 @01:43PM (#26196397)
> 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 by tptacek on Friday February 19, 2021 @02:22PM (#26196897)
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 by pjmlp on Saturday February 20, 2021 @06:38AM (#26203422)
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 by tptacek on Sunday February 21, 2021 @12:21AM (#26211034)
Somehow I think ISRG is not going to try to secure funding to rewrite core Windows components.