4 ms·

You seem to be right in large parts, however other econsystems and package managers don't have the same kinds of problems to that degree, since their package na

by dgb23 3y ago

You seem to be right in large parts, however other econsystems and package managers don't have the same kinds of problems to that degree, since their package names are namespaced. I'm not sure if this would solve this particular issue, it actually might, but name squatting in general seems to be far less of an issue with other package repositories.

MrBuddyCasino 3y ago
I expect to hear about the fallout of crate.io's decision to not use namespaces and have no procedures to claim names for several years to come. Its not like they weren't warned this would happen, or that there was prior experience with exactly this kind of issue (just ask the Maven team).
- dgb23 3y ago
  Is the rationale documented somewhere? I have a hard time to understand why this decision was made, especially in the face of prior art. To me it seems like a non-tradeoff.
  - pornel 3y ago
    I don't think there's an answer in one place, but various reasons have been given in many namespacing megathreads: • Some members think squatting is not a problem, let people take all names, and then people will invent creative ones, like nokogiri in Ruby. • Adding of namespaces only moves the squatting problem from squatting crate names to squatting namespaces. People like nice namespaces too. What if someone grabs an official-looking namespace like "aws", and what if that's a legit project? • Using usernames for namespaces makes typosquatting even worse, because many usernames are odd and hard to remember correctly (would you remember digits in winapi's owner handle? Is it BurnSushi, BurntSushi, BurnedSushi?) • crates.io relies on GitHub for identities, but GitHub usernames are not permanent. Crate names must be permanent. Letting the two out of sync creates new problems. • Crate names map to Rust identifiers, and there's a bikeshed about separators and ambiguities. • There's already a ton of non-namespaced crates, which must be supported. Having both namespaces and non-namespaces creates another bunch of bikeshed problems. • Having anti-squatting policy is laborious to enforce, and handling of disputes was a terrible drain of resources for npm. • crates.io is understaffed and can't deal with this right now. • people also proposed different approaches, like UUIDs/hashes/git URLs. There's a current RFC to use existing crates as namespace prefixes for projects.
    - epage 3y ago
      I think this covers it fairly well but wanted to clarify one item > There's a current RFC to use existing crates as namespace prefixes for projects. Thrs is not intended as a general purpose namespacing but to allow semi-open (rust) namespaces and should only be used if it makes sense in the code itself. EDIT: Another one: > crates.io relies on GitHub for identities, but GitHub usernames are not permanent. Crate names must be permanent. Letting the two out of sync creates new problems. GitHub is also an implementation detail and they don't want to couple features to github.
    - MrBuddyCasino 3y ago
      Thanks for assembling this list, I'll reply to each. > Some members think squatting is not a problem, let people take all names, and then people will invent creative ones, like nokogiri in Ruby. I think we can agree that time has proven this one to be wrong (predictably). > Adding of namespaces only moves the squatting problem from squatting crate names to squatting namespaces. This is why Maven uses two schemes, io.github.username (and similar) in case of Git hosting services, or proven domain ownership via DNS TXT records. There has been zero drama in many years of having this scheme. [0] > Using usernames for namespaces makes typosquatting even worse Yes this is not a good idea. > crates.io relies on GitHub for identities, but GitHub usernames are not permanent A "published artifacts may never be unpublished" rule should solve that, plus protecting a namespace (groupId) once it has been used to upload an artifact by credentials. > Crate names map to Rust identifiers TBH I don't get that one. It seems this is more like a technical question of how to mangle symbols? > There's already a ton of non-namespaced crates Maven had the same issue, it is no really a problem, just confusing bc for a while there will be duplicates (could be solved by redirects). > Having anti-squatting policy is laborious to enforce Understandable. I think using the Maven scheme, it should be fully automatable, but I'm not sure. > crates.io is understaffed Understandable. I suspect corporations could be interested in having this managed properly, as this is a security issue. Possible revenue stream via managed services (Maven does this)? > people also proposed different approaches, like UUIDs/hashes/git URLs Haven't looked at this in detail, seems inferior because mnemonics are important, and Git URLs alone are too limited. [0] https://central.sonatype.org/publish/#individual-projects-open-source-software-repository-hosting-ossrh https://central.sonatype.org/publish/#individual-projects-op...
  - matt_kantor 3y ago
    https://samsieber.tech/posts/2020/09/registry-structure-influence/ https://samsieber.tech/posts/2020/09/registry-structure-infl... is not "official" but attempts to sum things up, and includes a bunch of links to RFCs and other discussions with comments from crates.io team members.

by dgb23 3y ago

MrBuddyCasino 3y ago

I expect to hear about the fallout of crate.io's decision to not use namespaces and have no procedures to claim names for several years to come. Its not like they weren't warned this would happen, or that there was prior experience with exactly this kind of issue (just ask the Maven team).

dgb23 3y ago
Is the rationale documented somewhere? I have a hard time to understand why this decision was made, especially in the face of prior art. To me it seems like a non-tradeoff.
- pornel 3y ago
  I don't think there's an answer in one place, but various reasons have been given in many namespacing megathreads: • Some members think squatting is not a problem, let people take all names, and then people will invent creative ones, like nokogiri in Ruby. • Adding of namespaces only moves the squatting problem from squatting crate names to squatting namespaces. People like nice namespaces too. What if someone grabs an official-looking namespace like "aws", and what if that's a legit project? • Using usernames for namespaces makes typosquatting even worse, because many usernames are odd and hard to remember correctly (would you remember digits in winapi's owner handle? Is it BurnSushi, BurntSushi, BurnedSushi?) • crates.io relies on GitHub for identities, but GitHub usernames are not permanent. Crate names must be permanent. Letting the two out of sync creates new problems. • Crate names map to Rust identifiers, and there's a bikeshed about separators and ambiguities. • There's already a ton of non-namespaced crates, which must be supported. Having both namespaces and non-namespaces creates another bunch of bikeshed problems. • Having anti-squatting policy is laborious to enforce, and handling of disputes was a terrible drain of resources for npm. • crates.io is understaffed and can't deal with this right now. • people also proposed different approaches, like UUIDs/hashes/git URLs. There's a current RFC to use existing crates as namespace prefixes for projects.
  - epage 3y ago
    I think this covers it fairly well but wanted to clarify one item > There's a current RFC to use existing crates as namespace prefixes for projects. Thrs is not intended as a general purpose namespacing but to allow semi-open (rust) namespaces and should only be used if it makes sense in the code itself. EDIT: Another one: > crates.io relies on GitHub for identities, but GitHub usernames are not permanent. Crate names must be permanent. Letting the two out of sync creates new problems. GitHub is also an implementation detail and they don't want to couple features to github.
  - MrBuddyCasino 3y ago
    Thanks for assembling this list, I'll reply to each. > Some members think squatting is not a problem, let people take all names, and then people will invent creative ones, like nokogiri in Ruby. I think we can agree that time has proven this one to be wrong (predictably). > Adding of namespaces only moves the squatting problem from squatting crate names to squatting namespaces. This is why Maven uses two schemes, io.github.username (and similar) in case of Git hosting services, or proven domain ownership via DNS TXT records. There has been zero drama in many years of having this scheme. [0] > Using usernames for namespaces makes typosquatting even worse Yes this is not a good idea. > crates.io relies on GitHub for identities, but GitHub usernames are not permanent A "published artifacts may never be unpublished" rule should solve that, plus protecting a namespace (groupId) once it has been used to upload an artifact by credentials. > Crate names map to Rust identifiers TBH I don't get that one. It seems this is more like a technical question of how to mangle symbols? > There's already a ton of non-namespaced crates Maven had the same issue, it is no really a problem, just confusing bc for a while there will be duplicates (could be solved by redirects). > Having anti-squatting policy is laborious to enforce Understandable. I think using the Maven scheme, it should be fully automatable, but I'm not sure. > crates.io is understaffed Understandable. I suspect corporations could be interested in having this managed properly, as this is a security issue. Possible revenue stream via managed services (Maven does this)? > people also proposed different approaches, like UUIDs/hashes/git URLs Haven't looked at this in detail, seems inferior because mnemonics are important, and Git URLs alone are too limited. [0] https://central.sonatype.org/publish/#individual-projects-open-source-software-repository-hosting-ossrh https://central.sonatype.org/publish/#individual-projects-op...
- matt_kantor 3y ago
  https://samsieber.tech/posts/2020/09/registry-structure-influence/ https://samsieber.tech/posts/2020/09/registry-structure-infl... is not "official" but attempts to sum things up, and includes a bunch of links to RFCs and other discussions with comments from crates.io team members.