The Rust Foundation is Reviewing and Improving Rust's Security (i-programmer.info) 22
The Rust foundation is making "considerable progress" on a complete security audit of the Rust ecosystem, according to the coding news site I Programmer, citing a newly-released report from the nonprofit Rust foundation:
The foundation is investigating the development of a Public Key Infrastructure (PKI) model for the Rust language, including the design and implementation for a PKI CA and a resilient Quorum model for the project to implement, and the report says that language updates suggested by members of the Project were nearly ready for implementation.
Following the XZ backdoor vulnerability, the Security Initiative has focused on supply chain security, including work on provenance-tracking, verifying that a given crate is actually associated with the repository it claims to be. The top 5,000 crates by download count have been checked and verified.
Threat modeling has now been completed on the Crates ecosystem. Rust Infrastructure, crates.io and the Rust Project.
Two open source security tools, Painter and Typomania, have been developed and released. Painter can be used to build a graph database of dependencies and invocations between all crates within the crates.io ecosystem, including the ability to obtain 'unsafe' statistics, better call graph pruning, and FFI boundary mapping. Typomania ports typogard to Rust, and can be used to detect potential typosquatting as a reusable library that can be adapted to any registry.
They've also tightened admin privileges for Rust's package registry, according to the article. And "In addition to the work on the Security Initiative, the Foundation has also been working on improving interoperability between Rust and C++, supported by a $1 million contribution from Google."
According to the Rust foundation's technology director, they've made "impressive technical strides and developed new strategies to reinforce the safety, security, and longevity of the Rust programming language." And the director says the new report "paints a clear picture of the impact of our technical projects like the Security Initiative, Safety-Critical Rust Consortium, infrastructure and crates.io support, Interop Initiative, and much more."
Following the XZ backdoor vulnerability, the Security Initiative has focused on supply chain security, including work on provenance-tracking, verifying that a given crate is actually associated with the repository it claims to be. The top 5,000 crates by download count have been checked and verified.
Threat modeling has now been completed on the Crates ecosystem. Rust Infrastructure, crates.io and the Rust Project.
Two open source security tools, Painter and Typomania, have been developed and released. Painter can be used to build a graph database of dependencies and invocations between all crates within the crates.io ecosystem, including the ability to obtain 'unsafe' statistics, better call graph pruning, and FFI boundary mapping. Typomania ports typogard to Rust, and can be used to detect potential typosquatting as a reusable library that can be adapted to any registry.
They've also tightened admin privileges for Rust's package registry, according to the article. And "In addition to the work on the Security Initiative, the Foundation has also been working on improving interoperability between Rust and C++, supported by a $1 million contribution from Google."
According to the Rust foundation's technology director, they've made "impressive technical strides and developed new strategies to reinforce the safety, security, and longevity of the Rust programming language." And the director says the new report "paints a clear picture of the impact of our technical projects like the Security Initiative, Safety-Critical Rust Consortium, infrastructure and crates.io support, Interop Initiative, and much more."
New tune (Score:1)
Last week: "Rust is way more secure than C, you should rewrite linux!"
This week: "Rust is insecure, let's work on that."
Re: (Score:1)
Yep. Funny how that goes. I think they are just lying.
Re:New tune (Score:4, Informative)
The summary explains their effort relates to security of the project infrastructure. Nothing to do with the language. It's about admin privileges in the repository and signing releases.
The most programming-related are the tools to help programmers to analyse dependencies in their projects (in a way they can catch something like xz-utils backdoor in openssh). Once more, nothing in this news discusses the security of the language, only the infrastructure.
Re: (Score:3)
Ken Thompson Hack [cmu.edu]
Elephant in the room ==== ecosystem (Score:3)
Having to depend on thousands (tens of thousands?) of source code files written by other people, outside of the compiler, standard library, debugger team is the elephant in the room.
No one wants to address how modern software development now depends on thousands of packages of unknown quality, support lifetimes and utility.
Rust, or another more modern language, will eventually need to stabilize on a much much smaller set of core tools and libraries written by a small set of vetted developers.
This big ball o
Re: (Score:2)
No one wants to address how modern software development now depends on thousands of packages of unknown quality, support lifetimes and utility.
Some of which have an install process [github.com] that consists of
.
But it's written in Rust, so it must be secure.
Re: (Score:2)
Having a set of stable, well trusted, secure crates for achieving most tasks has been part of the Rust strategy for three or four years now.
Most of this is about lowering barriers to entry; it's a PITA to have to choose between three or four different crates that do effectively the same thing. But, it will have a positive effect on the security of the ecosystem also.
Re: (Score:2)
I think you can make a difference.
1) About the "trusting trust"
The "trusting trust" hack could exist at a time we depended on binary compilers that we had no control over. Right now we use free software compilers, built step by step since 3 decades. We can prove that no "trusting trust" vulnerability has been introduced into (for example) Debian compiler toolchain since 1994-1996 (or 1993 with FreeBSD), by replicating the build of from versions i to i+1. It is implausible that a vulnerability introduced bef
Re: New tune (Score:3)
Rust is insecure
Nobody said that.
Re: (Score:3)
Re: (Score:2)
It's written mainly in C++ with a lot of shim code written in Perl.
Re: (Score:2)
I dunno... (Score:2)
You just can't trust that those coders to know how to handle memory in that c-compiler program they compiled the Rust-written compiler in. Probably all kinds of leaks and overflows in that new Rust compiler. I mean those C coders can't possibly know how to do correct memory management. It's dangerous and too complicated, but with this new paradigm, all is safe. We can continue to hire low on the scale and all can code in safety.
Re:New tune (Score:5, Insightful)
A different set of concerns. You have security concerns that may be fundamental to the language, and then there's concerns around the logistics, which may be correlated with the language. This concern is all about the ecosystem logistics.
With C, the unique concern is how it doesn't do anything to help and forces you to micromanage memory bounds and allocation. So a trustworthy developer with trustworthy dependencies is at relatively higher risk of making a security problem through a third party being able to trick executables into accidentally reading and/or writing memory that wasn't meant to be read or written.
With the kernel, C and Rust as far as I can tell have fairly similar logistics, so this isn't too pertinent to concerns that might impact the kernel. So you just have the generally more sane behavior with respect to allocation and boundaries of data structures.
However, Rust like so many others has embraced trivial access to largely uncurated, self-published third-party code. The good news is a quick typing of the name of the library you know and love gets you that library. Bad news is you are one typo away from a malicious code. Or for maliciousness to come to the sanctioned package. Node(Javascript), Rust, Python, and Go all perhaps make it *too* easy to go grab whatever dependency without giving it a thought, in some cases having dependencies loaded at run time instead of build time, leaving the door open for arbitrary injection of third party code at any point. Fundamentally, this is high risk but they are trying to mitigate it. You *can* do a more traditional vetting and careful management of your dependencies with these languages, but the communities will look at you weird for being meticulous when you can just type a quick line in a file or run a quick command and be nice and fresh dependency you wanted.
Re: (Score:2)
However, Rust like so many others has embraced trivial access to largely uncurated, self-published third-party code.
Yeah, that's always the problem, right? Bad engineering decisions and mistakes lead to security flaws.
It's not the language, it's the programmer. A programmer who isn't trying to think of all possibilities that could go wrong, will always write insecure code. In any language.
If you're a "happy path" programmer, you can't write good code.
Re: (Score:2)
Learn how to be a "happy path" programmer and your code will be clearer, cleaner, safer, more secure, and easier to maintain.
The opposite, actually, because you haven't learned to take multiple complex paths and write them simple and elegantly.
But fortunately, hackers only use the happy path, they've never been the type to try to make your code crash.
Re: New tune (Score:1)
Happy Path like most web frameworks? They are all warm and fuzzy and cute until you actually have to make something useful with them.....
Re:New tune (Score:4, Informative)
> However, Rust like so many others has embraced trivial access to largely uncurated, self-published third-party code.
These things are not either/or. Having a large standard library many parts of which no one use but which are theoretically maintained is both a load on core developers and a large attack surface (python and java being obvious examples). Having a very large dependency graph with many trivial libraries and thirty different options for every piece of functional is hard to vet and again gives a large attack surface (javascript!).
Rust has gone the route of a small standard library, with external crates with well used and understood crates for most of the core tasks. It's a question of how well they do this.
How about a new syntax? (Score:2)
I know "it's just grammar" but damn if Rust doesn't have the most jarring grammar I've seen in the last few decades then whatever was worse had to have been blacked out from my memory.
Re: (Score:2)
Defects lay in the underlying platform (Score:2)