How Rust Improves the Security of Its Ecosystem (rust-lang.org) 45
This week the non-profit Rust Foundation announced the release of a report on what their Security Initiative accomplished in the last six months of 2023. "There is already so much to show for this initiative," says the foundation's executive director, "from several new open source security projects to several completed and publicly available security threat models."
From the executive summary: When the user base of any programming language grows, it becomes more attractive to malicious actors. As any programming language ecosystem expands with more libraries, packages, and frameworks, the surface area for attacks increases. Rust is no different. As the steward of the Rust programming language, the Rust Foundation has a responsibility to provide a range of resources to the growing Rust community. This responsibility means we must work with the Rust Project to help empower contributors to participate in a secure and scalable manner, eliminate security burdens for Rust maintainers, and educate the public about security within the Rust ecosystem...
Recent Achievements of the Security Initiative Include:
- Completing and releasing Rust Infrastructure and Crates Ecosystem threat models
- Further developing Rust Foundation open source security project Painter [for building a graph database of dependencies/invocations between crates] and releasing new security project, Typomania [a toolbox to check for typosquatting in package registries].
- Utilizing new tools and best practices to identify and address malicious crates.
- Helping reduce technical debt within the Rust Project, producing/contributing to security-focused documentation, and elevating security priorities for discussion within the Rust Project.
... and more!
Over the Coming Months, Security Initiative Engineers Will Primarily Focus On:
- Completing all four Rust security threat models and taking action to address encompassed threats
- Standing up additional infrastructure to support redundancy, backups, and mirroring of critical Rust assets
- Collaborating with the Rust Project on the design and potential implementation of signing and PKI solutions for crates.io to achieve security parity with other popular ecosystems
- Continuing to create and further develop tools to support Rust ecosystem, including the crates.io admin functionality, Painter, Typomania, and Sandpit
From the executive summary: When the user base of any programming language grows, it becomes more attractive to malicious actors. As any programming language ecosystem expands with more libraries, packages, and frameworks, the surface area for attacks increases. Rust is no different. As the steward of the Rust programming language, the Rust Foundation has a responsibility to provide a range of resources to the growing Rust community. This responsibility means we must work with the Rust Project to help empower contributors to participate in a secure and scalable manner, eliminate security burdens for Rust maintainers, and educate the public about security within the Rust ecosystem...
Recent Achievements of the Security Initiative Include:
- Completing and releasing Rust Infrastructure and Crates Ecosystem threat models
- Further developing Rust Foundation open source security project Painter [for building a graph database of dependencies/invocations between crates] and releasing new security project, Typomania [a toolbox to check for typosquatting in package registries].
- Utilizing new tools and best practices to identify and address malicious crates.
- Helping reduce technical debt within the Rust Project, producing/contributing to security-focused documentation, and elevating security priorities for discussion within the Rust Project.
... and more!
Over the Coming Months, Security Initiative Engineers Will Primarily Focus On:
- Completing all four Rust security threat models and taking action to address encompassed threats
- Standing up additional infrastructure to support redundancy, backups, and mirroring of critical Rust assets
- Collaborating with the Rust Project on the design and potential implementation of signing and PKI solutions for crates.io to achieve security parity with other popular ecosystems
- Continuing to create and further develop tools to support Rust ecosystem, including the crates.io admin functionality, Painter, Typomania, and Sandpit
It's already sooooper safe (Score:4, Informative)
It's a fine language and zealotry knows no temperance.
Re: (Score:2)
Don't worry. Another Cargo Cult will come along soon.
I'll carry on doing embedded stuff in C. I've been ignoring this shit since the 1980's.
Re: (Score:3)
I'll carry on doing embedded stuff in C.
Embedded stuff often has no dynamic memory (forbidden by MISRA) and uses event loops rather than threads.
If that's your situation, then there isn't any advantage to Rust. Memory and thread safety are its big advantages.
Even if you use dynamic memory and threads, but work alone or with a small team of experienced and disciplined coders, you don't need Rust.
But if you work on a big project with a large team with high turnover, mixed levels of experience, and pressure from management to get stuff out the door
Re: (Score:2)
It forces you to "do it right".
Except that it doesn't force you when there's this keyword "unsafe" which will provide the manager the means to supply the very important and impatient client the urgent feature for their software yesterday.
Re: (Score:2)
Except that it doesn't force you when there's this keyword "unsafe"
Unsafe blocks aren't a free-for-all. Many unsafe practices aren't allowed even inside unsafe blocks. For instance, you can't have pointers in two different threads with write access to the same data, even inside an unsafe block.
Unsafe blocks are also easy to identify. Just grep for "unsafe".
When you have a memory leak in C++, there is no equivalent shortcut to find it. So cancel your plans for the weekend.
Re: It's already sooooper safe (Score:2)
If you have a leak in C++ grep for new, or alloc. If you use the STL and smart pointers you wont get leaks.
Re: (Score:2)
For instance, you can't have pointers in two different threads with write access to the same data, even inside an unsafe block.
You can, but there's a good deal of indirection involved. Among other things, you'll have to convert it to a mutable raw pointer, and you'll probably want to pin it as well or else things probably just won't work as intended, then you'll need to pass the raw pointer between threads and dereference it once passed. But by design, it's much easier and less time consuming to just do it the right way.
The right way would be by using anything that is Send + Sync, such as atomics. Or you can (and this is common) wr
Re: (Score:2)
Doh, editing error, Arc/Mutex/RwLock are Send+Sync already. (Was initially writing something a bit more contrived.)
Re: (Score:2)
When you have a memory leak in C++, there is no equivalent shortcut to find it. So cancel your plans for the weekend.
If you have a decent build process, your build failed if a memory leak was possible...
Re: (Score:2)
Except that it doesn't force you when there's this keyword "unsafe" which will provide the manager the means to supply the very important and impatient client the urgent feature for their software yesterday.
Then that's a management issue. No language fixes that. So you're argument of "unsafe" makes it unsafe is a non sequitur in this context. This is like arguing that guns are unsafe because people can just point them at their head and kill themselves. DUH! Doing dumb shit leads to dumb consequences. Tool being used for that purpose notwithstanding.
Re: (Score:2)
Then that's a management issue. No language fixes that. So you're argument of "unsafe" makes it unsafe is a non sequitur in this context.
The non-sequitur that's you identified is actually in the claim that Rust protects you from bad management that is running a team with high turnover and excess expectations.
Did you even read the thread?
Re: (Score:3)
Re: (Score:2)
The same thing was said about C++ 20 years ago
I've never heard anyone make that claim about C++.
C++ has many safety features, including smart pointers, but the language doesn't enforce them (although your boss might).
Re: (Score:2)
if you work on a big project with a large team with high turnover, mixed levels of experience, and pressure from management to get stuff out the door and worry about technical debt later
Then you have lots of bugs, including security bugs, and a language with more abstractions to make it "safer" will result in higher short term output and potentially even an increase is bugs.
Also in that scenario Rust is probably being used in unsafe mode anyway, because they needed to link in legacy libraries.
The bugs it addresses only exist if you're not following best practices in the first place. If you're already not following best practices, none of this is likely to help. There is nothing there that
Re: (Score:2)
If you use external libraries, then you have the identical supply chain security problem that the Rust Foundation is addressing here and others have been working on.
If you're building everything from the metal up, like my last embedded project, the article is irrelevant to you.
I've been wondering whether to make bill of materials security my next specialty...
Re: (Score:3)
You rang?
Unix tools (Score:3)
So, when will all GNU tools and libraries (and Open/FreeBSD for that matter) be rewritten in Rust?
Re: Unix tools (Score:2)
Re: (Score:2)
Re: (Score:2)
Faster than you might expect: https://github.com/uutils/ [github.com]
Re: (Score:2)
Speak of fast, those are generally (a lot) faster than the standard gnu utils, often (but not always) because they multithread where practical.
Re: (Score:3)
Mozilla is working on it it (coreutils, findutils, diffutils) under the name uutils https://github.com/uutils [github.com] See also the blog of Sylvestre Ledru from Mozilla https://sylvestre.ledru.info/b... [ledru.info]
Re: (Score:1)
Meh, I think I'll wait for uuutils.
I thought Rust was safe? (Score:1)
How are you improving the security of a language that according to its followers cannot have security problems?
Re: (Score:2)
How are you improving the security of a language that according to its followers cannot have security problems?
That's only the Mac version of Rust.
If you're developing on Windows, you need the new security.
Seriously, isn't this "infrastructure" effort all about secured distribution of libraries?
Re: (Score:2)
isn't this "infrastructure" effort all about secured distribution
So, when is the Rust Store opening? Also how much does it cost per year to become a Registered Rust Developer + pubish an app? Asking for a friend..... /s
Re: I thought Rust was safe? (Score:2)
Re-read the title: the areticle is about the ecosystem, not the language.
Having a safe language isnâ(TM)t enough if the library you use has a secret backdoor password in it.
Sounds pretty unfinished to me (Score:2)
Anybody relying on this stuff? Not smart.
Re: (Score:2)
The linux kernel. https://www.kernel.org/doc/htm... [kernel.org]
Re: (Score:3)
You cited something, but you didn't read it first.
Your claim is that the Linux kernel is "relying" on Rust. Your link says they've made it possible to use it, for the purpose of evaluating if they want to use it.
The Rust support was merged in v6.1 into mainline in order to help in determining whether Rust as a language was suitable for the kernel, i.e. worth the tradeoffs.
Currently, the Rust support is primarily intended for kernel developers and maintainers interested in the Rust support, so that they can start working on abstractions and drivers, as well as helping the development of infrastructure and tools.
If you are an end user, please note that there are currently no in-tree drivers/modules suitable or intended for production use
These are the morons we have left on this once-great site.
Re: (Score:2)
Hahaha, no. Linus is just giving the Rust people enough rope to hang themselves. Which they most likely will do as they promote a culture of incompetence and tool-reliance. They are not smart enough to see that though. As Aighearach points out, you should have read your reference.
Re: (Score:2)
Anybody relying on this stuff? Not smart.
There's nothing at all smart about dismissing shit you don't understand like you always do.
You know, you're probably one of those slashdotters in the early aughts who, when they spoke of anything programming related, I just took their word for it as I never had any intention of ever doing software development and generally thought you guys knew what you're talking about. Now roughly 20 years later, having been there and done that, even with very little experience under my belt, I've realized just how stupid
Re: (Score:2)
Anybody relying on this stuff? Not smart.
There's nothing at all smart about dismissing shit you don't understand like you always do.
Hahaha, right back at you. You do not understand what I am doing here. Your mind is probably way too small to understand my comments and their nature. Does not make you special, too many fuckups are incapable of understanding that there are people way smarter than they are.
Re: Sounds pretty unfinished to me (Score:2)
And your response is...an entire paragraph of weasel words...
Can Rust security blowup like Java? (Score:2)
I remember when Java came out in '96 it was this secure language that could do no wrong. The message to developers was that you could write everything in Java - a browser, an OS -- it'd be super secure.
Then a decade or two later, Java (JVM) vulnerabilities and security patches suddenly began trickling out. I thought, "that's strange"... only to see the trickle turn into a flood: alert after alert, patch after patch, Java browser plugins disabled etc. Java
Two questions:
1. Is there an underlying theme to the
Re: (Score:2)
Is there an underlying theme to the Java security issues?
I don't remember Java promising security when it came out (though I was like 14 when it did) I strongly suspect that, if that was part of its promise, it's probably because so few people really understood how to write secure code to begin with. Back then people tended to look at bugs as just errors that are to be worked around until somebody gets around to patching them instead of thinking about how said bug could be exploited and used to create a disaster. Even when Java came out, gets() was still widely i
Re: (Score:2)
And to all those who insist C is wonderful because code they wrote in the 80s will still compile and run without changes -- no, there's a good chance it won't.
You give the compiled one flag telling it to use the old version, and it compiles just fine.
If you don't know... just shut up. Don't guess.
If you don't like null-terminated strings it says a lot about your level of thinking. You have to have a magic terminator in order to optimize cases of variable-length strings. If you use a heavy-weight encapsulation instead, you're spending a bunch of processor cycles and memory storage on that. Often that is worthwhile, but internally within a program it is often waste
Re: Can Rust security blowup like Java? (Score:2)
You give the compiled one flag telling it to use the old version, and it compiles just fine.
If you don't know... just shut up. Don't guess.
And just to clarify, you don't see anything at all wrong with what you just said?
If you don't like null-terminated strings it says a lot about your level of thinking.
Basically that I don't like strings that can be quietly fucked, possibly even maliciously so, by a non-printable null byte.
You have to have a magic terminator in order to optimize cases of variable-length strings. If you use a heavy-weight encapsulation instead, you're spending a bunch of processor cycles and memory storage on that.
So while you've been living under that PDP-11 for the last 30 years, the world has moved on to fat pointers. And no, that's not a penis joke, it's serious business. Basically you don't need a terminator byte and you don't have to deal with any of that other shit either. And yes, you can dynamically change y
Re: (Score:2)
Thank you!
Kind of sad... (Score:2)
Even in the open source community, everything needs to have a huge, aggressive marketing campaign.