Example: https://crates.io/users/mahkoh
Is this something that you should intervene to discourage? Or is it just part of the cut and thrust of things?
3 Likes
If there’s a crate name this person has registered you’d like to use, have you tried contacting them and asking if they’ll give you the name?
Looks like they squatted on all of those names 3 years ago. Only GitHub activity in a year is a Go project.
I’m especially impressed he grabbed the crate crate. Can that crate even work since crate is a keyword? 
4 Likes
Sounds like a challenge.
Well there must be something that can be done about it. If they're apparently not gonna use those names, then they should relinquish them.
3 Likes
I'm really hoping this is somehow valid Rust:
extern crate crate
...
A library crate cannot be called crate (or any other keyword), but (apparently) there is no such restriction on packages. A package can supply a crate with a different name if so desired.
error: expected identifier, found keyword `crate`
--> src/main.rs:1:14
|
1 | extern crate crate;
| ^^^^^ expected identifier, found keyword
A library called crate is usable (with nightly Cargo) but just annoying.
// ```toml
// cargo-features = ["rename-dependency"]
//
// [package]
// name = "testing"
// version = "0.0.0"
//
// [dependencies]
// renamed_crate = { package = "crate", version = "0.0.2" }
// ```
extern crate renamed_crate;
fn main() {}
1 Like
Previous discussions of squatting on crates.​io:
- Should people be allowed to “reserve” crate names?
- crate.io's policy/perspective on trust and crate squatting
As far as I know, the official policy continues to be crates.io: Rust Package Registry.
Squatting
We do not have any policies to define 'squatting', and so will not hand over ownership of a package for that reason.
4 Likes
I assume raw identifiers will also allow extern crate r#crate;
6 Likes
As far as I know, if you're the only owner of a crate, you can't relinquish ownership of it and re-release the name into the wild (if anybody could claim packages like that it might lead to some security problems), and even in circumstances like this, the crates team has said that they won't intervene, so the best a person would be able to do here is just ask politely...
That's a good point. I think that can be mitigated with some sort of key revocation that nullifies everything that made the package valid for previous users, but I might be wrong.
Squatting is a tricky problem to solve. If you go by inactivity, squatters might start pushing random commits to the crate once in a while (oops I just gave some of them the idea 
)
2 Likes
I agree that package squatting for the purpose of claiming them to yourself is deplorable. User mahkoh seems to have done exactly that, registering package names like audio and emoji.
I'm not very familiar with the ecosystem, and I would like know more. Did they more to a different approach?
As one of the people mentioned in that link, I would like to re-state my case for having some package names protected/blacklisted. It's not very hard to get into big trouble cargo-installing the wrong thing. Perhaps when you're tired you might make a mistake copying a package name from the web, and run cargo install install interestingpackage. Perhaps (like me) you watch a presentation that tells you to cargo install miri , so you do it, but you realise the presenter never actually reserved that name so you might as well just have gotten malware. So some package names (like install) should probably just be blacklisted, and names like miri should really be registered before you tell people to install it.
Given that those things didn't happen, I did what I thought was the next best thing, although I remain more than happy to blacklist/transfer those names. I understand that not everybody agrees with me.
kbknapp on Reddit writes
It's interesting to see the packages registered "Because someone might copy paste 'something' into the terminal and install a package which is a security risk." While I agree that could be an attack vector, I'd find it pretty hard to believe the crates.io: Rust Package Registry team wouldn't take down a package which was blatantly doing this.
but I disagree that this is a good approach. How will you know if such a package is malicious? It is really really hard (impossible?) to figure out what the contents of a package is, without installing it. The crates.io web site doesn't seem to have any support for this.
(Perhaps we should open a thread about making package contents inspectable from the web interface or otherwise.)
6 Likes
I was working on cargo this weekend and accidently messed up the syntax of the new rename dependency feature, I renamed foo to winapi instead of the other way round. Thank you for not deleting my hard drive, and for protecting me from someone who thought that would be funny!
1 Like
I've often thought this myself. Maybe it should have its own thread, if it's not been discussed before.
2 Likes
The example I gave is slightly annoying in that there can never be a difinitive http2 crate called http2, but not really a problem.
I think that the mods should intervene if a name like http had malware behind it. I think that malware is something that will get worse as rust’s popularity increases. Better to have policy/systems to deal with it now if possible.
2 Likes
It would be nice to have a curated central package repository like the AppStore is for Apple, Google Play for Android, etc. Squatting wouldn’t be a problem then.
Yet another example: https://www.reddit.com/r/rust/comments/9aaanw/cargo_crate_name_reservation_spam/
Now that’s just blatant. It’s not simply squatting for later own use, but “contact me if you want to use this name”? (Reminds me of domains, makes me wonder how much they charge…) WTF.
can crate names have dots in them? e.g. soniex2.hexchat-plugin? what’s the length limit? etc?
can crates “provide” a different crate? e.g. could the hypothetical soniex2.hexchat-plugin be a drop-in replacement for hexchat-plugin?