The lack of namespaces on crates.io is a feature • Hacker News Board

Re: The lack of namespaces on crates.io is a feature

#91

Post by rat87 » Fri, Sep 11, 2020, 7:31 PM UTC

papaf wrote: post #26

steveklabnik wrote: post #15

Earlier quoted context omitted.

We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm. Both the good and the bad. And also by the experience of going through GitHub hosting a RubyGems server and all the fallout that happened there.

We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm. Don't those package registries all suffer from not having namespaces? RubyGems in particular [1]. [1] https://thehackernews.com/2020/04/rubygem-typosquatting-malw...

Namespaced packages have almost the same problem

People can just have maliciously typeo-d namespaces

Actually you could argue it's worse since people tend to pay more attention to package names rather then namespace names

Re: The lack of namespaces on crates.io is a feature

#92

Post by andrewzah » Fri, Sep 11, 2020, 7:31 PM UTC

kibwen wrote: post #78

andrewzah wrote: post #29

Earlier quoted context omitted.

Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine. The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result. But with crates.io it feels like the opposite. I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short,…

> why namespaces are just -impossible- As mentioned elsewhere in here, this is a misrepresentation of the issue. The problem is that crates.io is a free, volunteer-run project with zero full-time employees who could be tasked with the drudgery of intervening in naming disputes or managing an identity layer. This is unlike GitHub and unlike "Java" (by which you probably mean Maven Central, which is operated by Sonatyp…

"could be tasked with the drudgery of intervening in naming disputes or managing an identity layer"

What do these have to do with the issue of namespaces?

Having namespaces would lessen naming disputes since users would be able to name their crate whatever. Any system will have disputes, so I'm not sure what the argument is here.

I understand why crates uses github for identity management, but it's not ideal that people are locked into using one specific git platform. Github is already an unavoidable entity, much like facebook, but this is a bit of a harder issue to solve without a lot more resources.

Re: The lack of namespaces on crates.io is a feature

#93

Post by andrewzah » Fri, Sep 11, 2020, 7:43 PM UTC

rat87 wrote: post #89

andrewzah wrote: post #29

Earlier quoted context omitted.

Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine. The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result. But with crates.io it feels like the opposite. I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short,…

What's right with package namespaces? How do they help at all? Where's the benifit? The cost is that package paths are longer and hard to remember. Also confusing because multiple packages can have the same name > I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short, meaningful name in English is taken at this point Squatting is not a major problem just nam…

"How do they help at all? Where's the benifit? [sic]"

The obvious one is people can put packages under their own namespace and not worry about naming collisions. If this were really such an issue, things like github,maven, or just about any other library manager would be impossible to work with. But that isn't the case.

"The cost is that package paths are longer and hard to remember. Also confusing because multiple packages can have the same name"

In 5+ years of programming I have not once had an issue due to namespaces. In both systems you still need to remember the author + repo name. Both systems would have multiple competing projects for a problem space. Etc. It's up to you (the engineer) to do your research before adding a library to your project. Namespaces or the lack of them will never fix that.

Name length? Really? Is ~5-15 chars vs ~20-25 so important? It's not like we're memorizing these things. This is not worth removing namespaces for.

Both systems have issues due to things being named the same. One example in rust is `http` and its related types, which get referred to by multiple crates. I ran into that recently when I pulled in various networking crates into the same project. Removing namespaces doesn't fix this.

"Squatting is not a major problem just name your package yourname-xml or randomname instead of yourname.xml"

I'm sorry but I cannot agree with this. Naming should not be a compromise. There's a reason we don't use random names or just random numbers.

Re: The lack of namespaces on crates.io is a feature

#94

Post by simon_o » Fri, Sep 11, 2020, 7:55 PM UTC

kibwen wrote: post #78

andrewzah wrote: post #29

Earlier quoted context omitted.

Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine. The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result. But with crates.io it feels like the opposite. I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short,…

> why namespaces are just -impossible- As mentioned elsewhere in here, this is a misrepresentation of the issue. The problem is that crates.io is a free, volunteer-run project with zero full-time employees who could be tasked with the drudgery of intervening in naming disputes or managing an identity layer. This is unlike GitHub and unlike "Java" (by which you probably mean Maven Central, which is operated by Sonatyp…

> could be tasked with the drudgery of intervening in naming disputes or managing an identity layer

That's why there are proposals that delegate the naming to outside systems with their own established dispute resolution rules.

This is due to the crates team requirement of "namespaces are not allowed to create additional work for the team".

So any proposal that makes them the naming authority is out from the get-go.

Re: The lack of namespaces on crates.io is a feature

#95

Post by wnevets » Fri, Sep 11, 2020, 8:05 PM UTC

cornstalks wrote: post #3

For those not familiar with Rust or the debate around this subject, "namespace" here is not like a C++ namespace (Rust's modules are analogous to C++'s namespaces). "namespace" here is about the crates.io package registry, not the Rust language. Let's say you have a crate (Rust's terminology for a package) named "foo". Inside "foo" you have a few subcrates (named "foo_bar", "foo_baz", "foo_qux"). There are a number o…

is there a TL;DR for why some people don't want namespaces for crates? Is it just because NPM does and javascript is bad or is there something else I'm missing? I couldn't imagine github or npm working well without them.

Re: The lack of namespaces on crates.io is a feature

#96

Post by renewiltord » Fri, Sep 11, 2020, 8:07 PM UTC

kbenson wrote: post #69

renewiltord wrote: post #7

Earlier quoted context omitted.

Interestingly, you can't name squat on GitHub. I just asked them for the guy squatting my first name and they gave it to me. Ah, the power of non-community-run product. You can do the right thing without having to worry about the slippery slope.

> I just asked them for the guy squatting my first name and they gave it to me. Your... first name? So "rene" (if I was to assume a few things about your username)?

Haha, that's not my real first name. You know, like how Ronaldinho's actual first name is Ronaldo? Like that. The actual name.

Re: The lack of namespaces on crates.io is a feature

#97

Post by arthur_pryor » Fri, Sep 11, 2020, 8:10 PM UTC

papaf wrote: post #55

steveklabnik wrote: post #28

Earlier quoted context omitted.

Everything has upsides and downsides. There are downsides to the Rubygems approach. However, typosquatting is an orthogonal problem to namespacing, you can still typosquat a namespace.

From the article: This is not the first time typosquatting attacks of this kind have been uncovered. Popular repository platforms such as Python Package Index (PyPi) and GitHub-owned Node.js package manager npm have emerged as effective attack vectors to distribute malware. "Orthogonal" suggests no connection but what I see above is a list of package managers that don't have namespacing.

> "Orthogonal" suggests no connection but what I see above is a list of package managers that don't have namespacing.

correlation does not equal causation.

how is it not apparent that typosquatting is possible regardless of whether namespacing is in play?

for example, URLs are namespaced, and are the classic example of typosquatting: https://en.wikipedia.org/wiki/Typosquatting

Re: The lack of namespaces on crates.io is a feature

#98

Post by ithkuil » Fri, Sep 11, 2020, 8:25 PM UTC

This is why I like the Go approach: just use an existing global namespacing system and delegate to it all ownership disputes etc: DNS + actual web servers serving traffic (not necessarily just got repos, since the "vanity imports" offer an indirection based in html meta tags)

Re: The lack of namespaces on crates.io is a feature

#99

Post by hombre_fatal » Fri, Sep 11, 2020, 8:28 PM UTC

j1elo wrote: post #35

papaf wrote: post #5

I remember when this came up because of the following user: https://crates.io/users/swmon

That is horrendous and it should be taken down due to obvious non-fair and possibly malicious intent.

So then they just change their script to only create 3 projects per generated username?

There's nothing you can do to prevent this except devise a system where it's inconsequential to register all of these names: namespaces.

If it bothers you that one person can do this with many packages, then presumably it bothers you that 100,000 people can do it benignly with a few package names which is what goes on in npm/ruby/cpan. The solution is to simply making them worthless.

Subreddits have the same problem.

Re: The lack of namespaces on crates.io is a feature

#100

Post by steveklabnik » Fri, Sep 11, 2020, 8:32 PM UTC

wnevets wrote: post #95

cornstalks wrote: post #3

For those not familiar with Rust or the debate around this subject, "namespace" here is not like a C++ namespace (Rust's modules are analogous to C++'s namespaces). "namespace" here is about the crates.io package registry, not the Rust language. Let's say you have a crate (Rust's terminology for a package) named "foo". Inside "foo" you have a few subcrates (named "foo_bar", "foo_baz", "foo_qux"). There are a number o…

is there a TL;DR for why some people don't want namespaces for crates? Is it just because NPM does and javascript is bad or is there something else I'm missing? I couldn't imagine github or npm working well without them.

> Is it just because NPM does and javascript is bad

Not at all! In fact, npm's implementation is why some are pro, but also why some say that it's not worth it; see https://news.ycombinator.com/item?id=24444852 for some npm specific sentiment.

(Incidentally, npm added scoped packages in 2015, after these decisions were made for crates.io. However, crates.io is still smaller than npm was then...)

There isn't really a TL;DR because this space is complex, and there's a lot of details, and they matter, and different people have different reasons for not wanting them. I think it's good that github has namespaces, but that doesn't mean I think that Cargo should have them, because they're fundamentally different services.

The short reason we gave back in 2014 was:

> Because namespaces are strictly more complicated in a number of ways,and because they can be added compatibly in the future should they become necessary, we’re going to stick with a single shared namespace.

from https://internals.rust-lang.org/t/crates-io-package-policies... which is linked in the post.