The malicious "rustdecimal" crate

If that's the case, perhaps looking for all merge requests at projects which are on gitlab, depend on the original crate, and where the merge request changed that dependency, might find the victim (if it's a public project).

Depending on how the CI is configured, it might automatically run on all merge requests, and it might expose important tokens (for instance, tokens to publish a finished and signed release) to the CI process. So this might be just the first step, and later we might be seeing a legitimate project publishing a malicious release due to this compromise.

Do you have examples ?

https://github.com/crev-dev/

I'd say that software that are distributed a bit too directly to users tend to evade such controls and by losing some of these constraints they also lose many of the guarantees they used to offer to their users. I do have absolutely zero trust in such software distributed on such channels that are nothing but a market place where fame replaces money, and where engagement can be zero without anyone noticing.

In Fedora, any packaged software is required to build offline (without any network access), and *only* from the sources provided; that means you at least have some hope of knowing what sources the binary was built from and rebuilding the software yourself.

As an example of the frankly incompetent crap vendors sometimes do that wouldn't fly in a serious distro, AWS's package for OpenDistro for Elasticsearch at one point used a pre-install script to download a binary from the internet upon installation and dump it in /usr/lib. This was done in a noarch package that's supposed to be architecture-independent! I remember it well because I had to spend time untangling a surprise broken upgrade in an ES cluster that had no internet access...

crates.io prominently shows not just the total download count, but a chart of downloads per version over the last 90 days. (See the bottom of https://crates.io/crates/rust_decimal). So if you want to make a malicious crate that doesn't look immediately suspicious and untrustworthy, you'll need to spend 90 days replicating that pattern of downloads.

I suspect you'd have more success by e.g. finding a popular but not-very-well-maintained crate, and sending a pull request that correctly implements a frequently-requested feature but includes a dependency on a new crate that you maintain yourself. Hopefully the maintainer will be glad to receive the patch and won't be concerned enough about the new dependency to reject it or rewrite it.

Developers who check the download history of the popular crate will have no reason to be concerned, and nobody has time to check the download history of every dependency of a crate before they use it. Then you can make a new release of your crate with some malicious code, and anyone starting a new project or running "cargo update" will receive your update.

(Old projects that don't explicitly update won't see the new version, because the old version number is stored in the project's Cargo.lock file, which is usually checked into VCS so every developer builds exactly the same code.)

For a conscientious application developer, I think one possible solution is to run "cargo vendor" to retrieve a local copy of all dependencies, and check that into your VCS. Use the net.offline config option to prevent Cargo accidentally using a non-local crate. Whenever you want to update dependencies: run "cargo update", "cargo vendor" again, then push it to your code review system and read the diffs of all the vendored dependencies. And whenever you want to add a new dependency to your project, look at the number and complexity of its indirect dependencies and consider the long-term costs of reviewing all that code and its updates forever, and balance that against the benefits it provides.