Rust team issues mitigation guidance and support contacts
1 Sep 17 2:02 PM · 7d ago · 5 posts · 4 sources · development 1 of 1
The project advised developers to enable MFA, verify account logins, be suspicious of unsolicited contacts, and to reach out to help@crates.io or security@rust-lang.org if they had account concerns.
“Be appropriately suspicious of cold outreaches, and ensure that any calls you have with new people are on platforms you trust — ideally, try to be the one who sets up the call on a platform you already use.”
Rust projectRust project / Rust Foundation Security issuer
The whole story posts the bright band is this development · numbered dots are the others · click one to jump
Reported in the same hours no headline names this development itself — these 1 claim were published in its stretch
-
first by Simon Willison, 7d ago
What people said 24 voices · best of 43 · verbatim
-
R
⚠️ We believe that there is an ongoing campaign targeting owners of popular crates and rust-lang team members that is attempting to compromise devices and accounts in order to use them to publish malware. See our blog post for details: https:// blog.rust-lang.org/2026/09/17/ targeted-attacks/
-
recently, systemd-the-organisation looked at introducing rust as a part of systemd-the-init. luca boccassi, one of the senior maintainers[1] of systemd-the-both, [raised some good points about it](https://github.com/systemd/systemd/pull/43551#issuecomment-5445121831). i've stripped what i'll describe as somewhat _extreme_ exaggerations around…
-
It's not a bad design choice just because it has consequences. Rust also doesn't have the financial backing of languages that seem to be able to afford a kitchen sink in their std lib. Python also suffers from stdlib rot from people not maintaining parts of it, and C++ can't fix their stdlib speed deficiencies because of ABI issues and backward…
-
C
The Rust team warns of a social engineering campaign targeting core members and owners of popular packages https:// blog.rust-lang.org/2026/09/17/ targeted-attacks/
-
The C ecosystem only fares as well as it does because it did so badly upstream that the distros had to develop their own C package managers... and the assumptions they make about dynamic linking and build processes do very much make them C package managers. (See…
-
Any config file these days will be JSON. Serializing objects to disk? Json. Python, PHP, java, go, ruby, c# and and ofc JS all ship json in their stdlib. The question is really: which languages don't ship json parsing
-
This is legitimately scary. Any piece of software that depends on open source (which is almost *every* piece of software) has a network of human beings who are potential attack vectors - everyone with publishing rights to any of the packages in the dependency network for that software. I guess our best defense right now is [dependency…
-
XML is still used today, in fact I've made multiple commits to different XML files this week alone. In fact, I've found it easier to work on with AI. I don't see XML going anywhere anytime soon.
-
Wow. I'm not in any way prominent, but I'm glad I'm already doing things which would make me think twice about something like a "missing codec" message, and treating cold outreach as inherently spammy/scammy. Now to expedite retrofitting my development setup so my only Rust toolchains exist inside Docker containers so I can trust that I don't…
-
Wait, wasn't the best language with the brightest future among all the other languages? The rust fanatics have beeing saying so for so much long time
-
> every now and then i'm reminded of the build.rs file[2] and how normalised it is, even to me, and it makes me shiver a bit. I don't think there's anything wrong with running arbitrary code during the build. If you're a developer, you're almost certainly building the package with the intention to run it right after. If you're a distro maintainer…
-
I’d recommend posting the output of the dependency analysis somewhere—they can be pretty subtle and I don’t think the count of dependencies is always that helpful. For instance, sometimes a single project will distribute 10 or 20 crates because they make the crates modular.
-
Beyond modularity, they also speed up the build process, sometimes significantly. Naively counting dependencies is a terrible metric to base opinions on; the alternative is: do **you** want to write the hundreds of thousands of lines of code you're depending on instead?
-
Do you think that's hyperbole when we're discussing dependencies in the hundreds? I just cloned the `systemd` repo, it contains over 1M lines of just C code.
-
Dependency Cooldowns in Rust: https://cooldowns.dev/#cargo (And other programming languages)
-
> That being seemingly acceptable for an LSP server has honestly turned me off the entire LSP ecosystem. This is absolutely not a flaw with LSP; it's a flaw with specific LSP servers, most prominently rust-analyzer and elixir-ls. There are lots of LSP servers that don't have this problem, (at the risk of no-true-scotsman, I'd say every good LSP…
-
That is the argument against using dependencies — there is also an argument for using them, and the optimal point on the spectrum is somewhere in between, to the right of most C projects but to the left of many Rust projects.
-
> Instead of just blindly downloading the latest version the package author has uploaded My `Cargo.toml` for applications are generally very specific on which version they rely on, and rely on my `Cargo.lock` to make updates an explicit step. cargo is not updating dependency versions behind your back, it requires either explicit steps (manually…
-
So... This is a mess but mostly it is not a PL problem. It is a build system problem with some ramifications into PL/compilers. But mostly it is a build system problem. And largely a build systems interactions with other build systems problems. And the sad reality is that there is a lot of work to be done there. But there are no easy solutions…
-
Ironically, the C ecosystem fares really well here, since I can just use my distro's package manager to manage dependencies. Instead of just blindly downloading the latest version the package author has uploaded, it's subject to my distro's policies - and I even get the choice of which distro's policies I prefer! Debian Stable keeps packages…
-
The systemd repository contains quite a large number of things, a lot of them implemented from first principles in order to avoid failure cases in existing solutions or libraries (and probably ending up discovering others :D). So that's the main reason it's that large. And I think it also clarifies that for low level code it's wiser for a project…
-
If systemd is happy to reinvent the C wheels, they should have no problem reinventing the Rust wheels. So their "Rust pulls in too many deps" argument falls flat ?
-
I agree that the culture of implicitly trusting large numbers of dependencies¹ is dangerous. > i'm unsure there is a way "out" at all, really, especially as both programs and programming have become more and more complex. I think that the best available approximation of a way out is to replace implicit, unexamined trust in dependencies with using…
-
> This is a mess but mostly it is not a PL problem. It is a build system problem with some ramifications into PL/compilers. I think there would be less of a mess if there were more capability-oriented library design, such that code could be sandboxed without heavyweight virtualization (no need for hardware VMs or OS containers or restricted…
All 1 developments of Rust project warns of coordinated attacks on prominent… →
LobstersHacker NewsRedditMastodonNewswires