Unlike javascript, where at least it is an interpreted language people can audit, you would have to reverse engineer these binaries to figure out what they do.

If you cargo install something you get source code (unless the library packages a binary, but that's the same as if it were JS or Python or C). Rust dependencies don't become binary until the final product.

Auditing Rust binaries isn't much worse than auditing minified and uglified JS. I've done both.

EDIT:

Rust

Rust is doing pretty poorly right now.

among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

https://kerkour.com/rust-supply-chain-nightmare

I just went through the article and I don't think I agree with the assessment that "Rust is doing pretty poorly right now." It feels disingenuous, given the content of the article you linked:

826 crates match their upstream repositories at the revision they were built at. 74 crates have revisions that cannot be found in their repositories, whether due to later squash merges, rebases or revisions simply not being pushed. 73 crates do not have VCS info, either because they were built with old Cargo versions, built with --allow-dirty, or not built from a repo clone at all. 77 crates do not declare a repository in their Cargo manifest. 7 crates would match their upstream repository but for one or more symlinks being incorrectly handled. 3 crates declare repositories that do not exist. 3 crates have submodules that do not exist. 3 crates cannot be found within their repositories. 3 crates cannot be built due to cargo package errors. ... Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

Cargo distributes libraries as sources, not precompiled objects.

This is how all language package managers work, unfortunately

npm does actually support signing and provenance (tracking how the package was built), so in some ways it can be more secure than other package managers. https://docs.npmjs.com/generating-provenance-statements

If you use one of the CI/CD systems they support (currently Github Actions and Gitlab CI), it can attach a signed attestation to the package stating the commit hash that was used to build the package, along with the steps taken to build it. This is combined with trusted packaging using OpenID Connect with short-lived tokens that are only obtainable in the correct CI environment, rather than using access tokens or username and password.

It only supports some CI systems because they have to guarantee that the connection between the CI system and npm is secure.

Some of the recent issues have been attacks on the CI system, rather than npm itself. For example, a Github Action that's only supposed to run for commits to the main branch, but unintentionally runs for some subset of pull requests too.

Of course, all this stuff is optional, and pushing to npm directly from a developer's computer still works and is still not verifiable at all.

I think the best approach is what Flathub/Flatpak, F-Droid (Android) and Composer/Packagist (PHP) do. You provide your repository URL, and they build the code on their end. Packages are always guaranteed to be built from code in the repo.

Debian Linux is also moving towards requiring repeatable builds, meaning that a package built from source should be byte-for-byte identical to the package in the repo.