With the recent (/ another ) npm disaster , what does crates.io do differently to prevent such a scenario? What does prevent a crates maintainer to distribute the API token to somebody else who then uploads malicious code?

Nothing, I'm afraid. This particular attack is very tough to prevent, because: there was no hacking/stealing, the package was given voluntarily. The usual protections like 2FA, code signing, etc. are to keep strangers away, but this was a breach of trust, not a breach of systems. the maliciou…

The only significant difference is that this attack was only present in the minified JS code, but not the source code. The equivalent in Rust would be a binary that does not match the source. Crates.io only distributes source, so that aspect could not happen. Ultimately, you are downloading arbitra…

However, source in crates is not formally connected to git repos, where people look at the code. Downloading and inspection of package tarballs is possible, but rather obscure feature, so I wouldn't count on people actually seeing code being compiled. I hope the project like crev in the thread I've…

Looking at code created by a malicious programmer may not be as helpful as many believe. Ka-Ping Yee did an interesting exercise as part of his thesis. See page 148 of http://zesty.ca/pubs/yee-phd.pdf . He planted 3 bugs in a 100 line region of a single file and told the reviewers where to look. …

Vulnerability obfuscation is an orthogonal issue, and using it to dissuade improving transparency of package contents is security nihilism. Having obvious, accessible correspondence between repositories and published crate versions still greatly improves the transparency of packaging and provides th…

Also remember that git repositories can be force-pushed, so there's no long-term guarantee that published code will match the repo, unless this is continuously audited. You might still want a simple sanity check for normal developers, but bad actors could just hide their actions.

No attempt at security nihilism from me. Even a malicious programmer can get caught via code inspection. My point is simply that detecting purposely planted vulnerabilities is harder than many people think.

You can re-push a particular branch or tag, but it is not feasible to forge a commit hash from arbitrary contents.

Does GitHub guarantee that it will keep that dangling commit hash around? Or do you think that it's enough that you could tell that the published commit disappeared?

No, it will not keep the dangling commit hash around. But if you clicked a link to a particular commit hash, you would either get the original contents of that hash, or a not-found error. You would not be shown something different at different times. Also the Github UI and API lets you see who has s…

How does crates.io differ from npm

community

kornel November 27, 2018, 11:35am 2

Nothing, I'm afraid.

This particular attack is very tough to prevent, because:

there was no hacking/stealing, the package was given voluntarily. The usual protections like 2FA, code signing, etc. are to keep strangers away, but this was a breach of trust, not a breach of systems.
the malicious code was smart enough to activate only in a specific scenario, so it was harder to detect.

Previous discussions on the topic:

4 Likes

Topic		Replies	Views
Are Rust crates secure?	71	7065	January 12, 2023
Yet another npm supply-chain attack. Is Cargo any safer? community	60	4062	March 29, 2026
Aren't there any efforts to bring Rust's dependency number down? help	125	9344	June 6, 2021
Regarding the Security / Safety of Libraries on Crates.io	34	3666	February 2, 2022
What about crate injections? community	16	1582	October 19, 2019

How does crates.io differ from npm

Related topics