4 ms·

Note that this problem of squatting (like many others security problems) is mostly a consequence of unmanaged repositories where developers publish themselves (

Note that this problem of squatting (like many others security problems) is mostly a consequence of unmanaged repositories where developers publish themselves (like crates.io here, npm, pypi or the various "app stores"). Well-tended community-organized repositories, like most linux distribution have, do separate the role of package maintainer. This makes a much needed buffer between users and the developers, which regularly have contradicting interests, security-, support- and integration-wise. See ddevault's two very clear explanations of this issue: https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html https://drewdevault.com/2019/12/09/Developers-shouldnt-distr... and https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job....

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...
miki123211 3y ago
IMO package developers shouldn't be the ones managing package repositories (and duplicating ICAN's job when naming is concerned.) Package management is an inherently political activity, and encouraging centralized package registries is, in my opinion, a bad decision in the long run. The security issues are one important problem, but sooner or later, somebody will have to deal with the "what do we do about excellent packages that many people lean on, but that come from a racist and fascist transphobe" problem. There's no good solution here, the choice is between potentially breaking a major part of your ecosystem or angering a violent pitchfork mob on social media, potentially with many corporations who are major ecosystem participants behind their backs. There are also other issues related to trademark infringement, patents, DMCA handling (and packages which are illegal to host in your jurisdiction but perfectly legal in the one of their developers), and important financial contributors bullying you into taking actions that serve their interests. A better way is to follow the lead of Go (or at least pre-module Go) and use git repositories (but not necessarily with repository-based import paths) instead of your own package registry.

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...

miki123211 3y ago

IMO package developers shouldn't be the ones managing package repositories (and duplicating ICAN's job when naming is concerned.) Package management is an inherently political activity, and encouraging centralized package registries is, in my opinion, a bad decision in the long run. The security issues are one important problem, but sooner or later, somebody will have to deal with the "what do we do about excellent packages that many people lean on, but that come from a racist and fascist transphobe" problem. There's no good solution here, the choice is between potentially breaking a major part of your ecosystem or angering a violent pitchfork mob on social media, potentially with many corporations who are major ecosystem participants behind their backs. There are also other issues related to trademark infringement, patents, DMCA handling (and packages which are illegal to host in your jurisdiction but perfectly legal in the one of their developers), and important financial contributors bullying you into taking actions that serve their interests. A better way is to follow the lead of Go (or at least pre-module Go) and use git repositories (but not necessarily with repository-based import paths) instead of your own package registry.