Cargo package aliases

derekdreery · 2017-09-06T15:20:27.536Z

I just accidentally used error_chain instead of error-chain in my Config.toml. I was wondering if error_chain should be reserved, so that if you try to use it, you get an error saying to use error-chain instead. If someone used the name error_chain and implemented different functionality, you may end up with unexpected errors and wasted time. Or, someone may upload a module that looks like error-chain, but does something malicious.

So would it be advisable, for certain popular packages, to reserve aliases for those packages (I think the most common error is using the wrong one of - and _), and print an error saying “this package name is reserved because it is very similar to <x>, did you mean to use that package?”?

Ixrec · 2017-09-06T15:35:16.862Z

I think https://github.com/rust-lang/cargo/issues/2775 and https://github.com/rust-lang/rfcs/pull/940 contain a lot of the past discussion on this topic.

derekdreery · 2017-09-06T15:44:57.796Z

Thanks for the links. They address the issue of using - in crate names (now disallowed), but they allow - to be used in package names in cargo.

I think this still leaves the problem open - I read about including '-' == '_' in case-insensitive equivalences, which seems sensible, but is not backwards compatible. However, even if you don’t apply this rule for all crates, you could still apply it for very popular crates.

dtolnay · 2017-09-06T16:38:37.780Z

Cargo will prevent you from publishing an error_chain crate if error-chain already exists, and vice versa.

I still think Cargo.toml should resolve to error-chain if you write error_chain, and resolve to serde_json if you write serde-json. Then it becomes up to the developer’s preference what they write in Cargo.toml, and they can be consistent. Currently every Cargo.toml will contain a confusing mix of ‘-’ and ‘_’ crates. Would love to see someone write an RFC for this!

derekdreery · 2017-09-07T07:55:27.188Z

Brilliant! I didn’t realise that you were already not allowed to publish crate_a and crate-a, so that means there’s no problem. I also agree that it would be nice if you could use all crate-a format or crate_a format.

Eh2406 · 2017-09-07T16:57:28.814Z

Well with the npm-malicious-packages I don’t think that “there’s no problem.” We still don’t have a typo proof system, just a -/_ proof one.

How many crates are levenshtein< 1 from each other?

So I descended into the BurntSushiVers…

check out crates.io-index and use @burntsushi’s walkdir to list all the names.
convert all the names to lowercase and _ -> -
use @burntsushi’s fst to make the list searchable.
use @burntsushi’s fst-levenshtein to search the fst for each name.
save the results to a gist.

Tada 3909 matches!

Eh2406 · 2017-09-08T21:58:20.633Z

So that file is overwhelming. Let me see if I can find some more interesting subsets.

The 97 that match one of the top 100 recent-downloads or the 105 that match one of the top 100 downloads.

What are other good questions we could be asking?

derekdreery · 2017-09-09T15:24:21.906Z

Do you think there should be a manual audit of the crates with names similar to popular ones? I think the most dangerous are extra hyphens (e.g. mycrate and my-crate)

derekdreery · 2017-09-09T15:27:00.480Z

I can see numtraits and num-traits

Edit not saying that is malicious, just follows the pattern

anatol · 2017-09-10T01:16:46.628Z

Related idea that has been discussed a while ago is to have Crates repository post-moderation

system · 2019-03-25T08:28:58.662Z

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.