Hello everyone! Earlier today the crates.io team identified a user who was impersonating an official account, and programmatically spamming the registry with empty packages that contained a suggestion to create new issues on the crates.io issue tracker.
It was noticed fairly quickly, and actions were taken to stop the publishing of future packages. You may have noticed the tweet from @cratesiostatus:
The crates.io team will be providing a full report on this later on blog.rust-lang.org. Thanks for your patience.
Saying “I know this will happen and I worry it won’t change policy” doesn’t mean you’re complicit or involved in it. If it happens, it just means you guessed right.
They didn’t “worry it won’t change policy” – they declared they will not. It’s not too surprising that this might spur a “greyhat” sort of person to want to challenge this. (Assuming good intent on the part of that spammer.)
I did not "dare" anyone to do anything. This comment is beneath you, just as this entire incident is beneath the Rust community. I feel disappointed and sad that so many of our community members seem to be unwilling to engage with this subject with nuance and maturity.
There exist egregious behaviors that will cause the crates.io administrators to take responsive actions. I think this should be obvious to anyone. Impersonating the crates.io administrators to try to create controversy that will push us to change our policies is, in fact, one such egregious action. I think this should also be obvious to anyone, but apparently it isn't.
The fact there are ways that use the cargo publish API that require a response from the administrators doesn't mean that wasting everyone's time by doing that will change the policy regarding other uses of the cargo publish API that we have determined are allowed. This, again, should be obvious to anyone.
(This is not an official response. I am not a crates.io administrator.)
I’m sorry for the flippant response. It comes out of frustration, as you undoubtedly know. I’m honestly not sure how to respond to your post, when you declare all of your opinions “obviously” true, but I’ll just state mine, without any such assertions.
I am also disappointed in lack of “engagement” on the issue of squatting, but apparently we disagree about what engagement would mean. For me, it would mean a genuine effort to craft a policy that, while likely not being perfect, would at least state the community intention to have a crates repository that isn’t full of spam. Instead, we had a steadfast refusal to consider spam a problem, and here are the continued consequences. The team members have asked for patience in anticipation of a full report on this incident, so I won’t say anything further.
I don’t have any opinion in favour or against namespacing, but this situation is ridiculous.
In which world are people so passionate about the need of having namespaces, that they are willing to engage in the malicious activities that namespaces would protect against just for the sake of proving that using namespaces is necessary?
In other words, the main argument in favour of namespaces right now is protecting against people trying to prove that namespaces are necessary.
First, let me agree wholeheartedly that impersonating a crates.io administrator is unacceptable and should result in some sort of punishment.
However, as mentioned even by the Reddit mods, the topic of squatting comes up once a week. It is a problem that needs to be discussed and taken seriously, and several members of the Rust community, as seen in this thread and in the numerous Reddit threads, feel that it has not been taken seriously and repeatedly been dismissed. There are other problems with the current crate naming solution as well, which are not malicious, but namespacing (with perhaps an “official” namespace for Rust-team-maintained crates) would alleviate these issues. I agree that the actions taken by this malicious user are not the proper way to draw attention to the problem, but that is no reason to continue to ignore the naming problem.
I would really like namespaces for a different reason--If I'm working on a crate for, say, logging things in Rocket, I don't want to publish a crate named rocket-logger unless I'm willing to take on the maintenance of such an official sounding crate--anyone who searches for "rocket logger" will find it, and it would be reasonable to assume that it is an official crate from the maintainer of Rocket, but it's not. With namespacing, it could be more obvious that this is not an official Rocket plugin, but a third-party one, and I'm not committing to the same level of maintenance responsibilities. Currently, my solution is to not publish to crates.io and to add the git repo to my Cargo.toml instead.
I’d say, if rocket-* is for official rocket crates, and rocket insists on publishing on crates.io, then you should use *-for-rocket for unofficial crates on crates.io.
Personally, I don’t want namespacing, I want federation. I want projects to run their own repos on their own domains, and I want crates.io to fetch and cache those repos, and anyone using those repos can safely publish on crates.io or anywhere else and rest assured that their crate will be available even if third-party repos go down, because those repos will be cached on the same server you got the crate from.
This is, effectively, DNS-based namespacing, but it’s also decentralized/federated, as each DNS owner can control/moderate their repos however they like. This would make the Rust/Cargo ecosystem extremely censorship-resistant (altho it won’t do much on the community end), and heavily benefit big crates like rocket, diesel, gtk-rs, etc.
Please, everyone. Again, as I said above. Please keep the discussion about namespaces to the threads about namespaces. This is all very offtopic here. If this continues, I’m going to have to lock it, which is unfortunate.
I’m seriously baffled by the amount of what I would call “victim blaming” in this thread. I someone does something which is not acceptable, saying “yeah but you had it coming” is not a great way to react. Saying “yeah what they did isn’t cool but they’re right on principle” is neither. (You may agree with them on the squatting matter, but this is not an appropriate situation to state that.)
I’m all for a constructive discussion of squatting policies. This incident does everything to make it less constructive. I therefore believe that it would be in our all interests to keep these matters separate and discuss squatting independently of the tantrums of a single individual.
Somewhat separate from the issue of official policy for crates.io, one thing I think is very important is the ability to have separate repositories for cargo, along the lines of crates.io. I don’t think it makes sense to tie the entire ecosystem to a single implementation, especially since many members of the community disagree strongly with the implementation and policy for this platform. For example, the current implementation of crates.io is unusable without javascript, and there doesn’t seem to be any movement towards fixing that. Having a system for third-party crate repositories would be beneficial for other reasons too, such as environments where the official server would be inaccessible. Currently the crates.io repository is somewhat favored by the cargo build tool, which is unfortunate. The only ways to get non-crates.io packages is via git or a file path. Ideally, there should be a way to use alternative package repositories in just as ergonomic a way as crates.io.
I don’t think that the correct response the official team not taking namespacing and frontend issues seriously is necessarily to make a new system, but I think the option should be there for a lot of reasons.