171–180 of 244 posts
Earlier quoted context omitted.
And? Google can't decide to fund organization that rewrites open source projects, or what? How is that different from forking the projects - apart from Google not taking anything at all?
[flagged]
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.
Honestly, I'm getting more and more disappointed by the quality of discussion here on HN.
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.
Earlier quoted context omitted.
If all Google wanted was GPL- and AGPL-free code, they're quite capable of assigning their own engineers / contractors to work on it rather than the more tortuous route of going via a 3rd party
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…
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
This.
* Languages with significant runtimes are going to be rejected by project maintainers; nobody is going to rube-goldberg a GC into an existing project just to replace a risky component when the option not to do that exists.
* Languages with insignificant adoption are going to be rejected by project maintainers because why take a flyer on an unknown quantity (not just technically but in terms of where the community will be 5 years from now) on a project you've been maintaining for decades? Say what you will about the Rust community and its long-term financial viability but the industry is pretty much already committed to it.
I'm fine with Rust but, like, not it's biggest fan (strongly prefer Go) but Rust pretty clearly hits the sweet spot being targeted here. I think you can assume safely that most of this work will be done in Rust.
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
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…
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.
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).
Earlier quoted context omitted.
Replying to myself as I cannot edit anymore. As others pointed out, it’s not clear who will do the rewrites. Based on the curl example, it might be the maintainers. It would have been great if they could state that concretely. I’m also wondering why there’s a middle man instead of funding the projects directly, but that’s another story.
I'm the head of ISRG, the "middle man" entity you're referring to. We have a memory safety initiative in which we plan and fund projects to move popular open source software to memory safe languages. For each plan we make we seek a funder - in a couple of cases now that has been Google, but it may be others in the future. We are in the "middle" of the financing in the sense that funding passes through us, but the mem…
If I understand correctly, this is an initiative that might have multiple sponsors, so it makes sense to have a central entity organizing it, and following up with all the projects involved. This makes perfect sense to me now.
Also, I was not aware that your org is behind Let’s Encrypt. This puts things into a very positive light.
It might make sense to post a sibling blog post/announcement to explain what this project is about and how it would work. I feel that Google’s post left a lot of questions to be answered.
If you don’t mind me asking, is rust the only language that you have in mind? Would go work as well?
So, its not enough that anybody that don't want to rewrite millions of lines of code in Rust because its just pure insanity, need to be constantly harassed and forced to feel ashamed (or feel even feel guilt) because "how in the world you did not did this code in Rust"
Now there's a whole INSTITUTION to funnel the scarce resources, not by fixing the security bugs but by forcing others to Rewrite Everything In Rust® or else they will have their popular projects hijacked by highly paid engineers from companies with unlimited financial resources to rewrite the whole thing in Rust leaving the maintainers of the original project eating dust if the don't conceive?
If this is not going to support the source code maintainers to patch the bugs in whatever technology they are using, this is the Rust bullying that used to be just annoying social dynamics, being take into another level.
Daniel Stenberg and libcurl will be exemplary nailed so others feel more inclined to follow or else see their projects being taken out of their hands if they do not consent.
Imagine if you are a open source maintainer with scarce resources, being approached by an institution that promise you to give you some funds, but only if you show a plan to rewrite the whole thing in Rust?
Edit: Just follow the Stenberg tweeter if you are curious https://twitter.com/bagder to see all the pressure this guy have being taken lately.
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? Z…
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…
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.