crates.io isn’t substantially technically different from npm in this case. This makes it all the more important to keep crates.io different in terms of social norms.
What I find the most distressing about the latest npm incident is how many people in that community (I believe Gary Bernhardt when he says some of the commenters are other npm module authors) respond that giving update control to a previously unknown person was either OK per se or that it was OK because the recipients of the malware hadn’t paid the original module author anything.
Debian has a package manager that’s different in the sense that the upstream authors aren’t (generally) the ones who upload packages to apt repos. However, as a matter of social norms, at least in my experience of talking with Debian developers and listening to Debian developers talk with each other in social settings, Debian is also very different. There seems to be appropriate awareness of being able to publish software in a manner that results in other people’s computers automatically running it being a serious thing.
So if something like this happens with crates.io, the positioning in terms of social norms matters, and we need clear signals from the Rust community at large that cavalier treatment of the power to publish updates is not OK (i.e. we should align the social norms closer to Debian than npm when it comes to taking seriously the power to publish updates; to be clear, I’m not advocating for Debian frequency of updates).
In particular, I think as a community, we need to make it clear that:
- Whether the software you provided to someone required a fee in exchange or not (likely not in the case of crates.io), if you no longer wish to provide new versions, it doesn’t mean that it’s OK to give away the power to provide automated (as in
cargo update) updates in cavalier manner.
- If someone shows up and offers you money to buy your crate and the power to upload new versions to crates.io under the same name, you should decline. (Even if you could use the money.)
- If you no longer wish to maintain a crate you wrote but someone else still needs the crate and would like to take over maintainership, you should accept only if you have previously seen the person participate in the Rust community in a way that suggests they have legitimate goals and aren’t seeking the update power of your crate for malware purposes.
- If in doubt, transfer the crate update control to rust-unofficial.
- If you can’t be bothered to do anything at all, literally do nothing (i.e. it’s better not to transfer update control at all than to transfer it in a cavalier manner).
Now, for the third point, nihilists will say that anyone, even if they’ve published useful crates on their own previously and otherwise participated in the community, could be a secret agent playing a long game, so it’s hard to articulate exact criteria for when you should believe that the person you are transferring update control to is wishing to take on the maintenance of a crate for legitimate reasons, but clearly it should not be OK to transfer update control to someone whose track record you know nothing about.
On the side of publishing crates, in order to be considerate to what transitive dependencies you expose to the people who depend on your crate, so you should try to make a common-sense assessment of your dependencies based on effort indicators (code and documentation quality) to rule out low-effort bad actors or on community reputation of the authors. (Obviously, this wouldn’t have protected against the npm case at hand, since the original module author, as I understand it, had the track record of having published a ton of legitimate modules, but that didn’t imply an appropriate attitude to update control changes.)
