4 ms·

> Rust crates need namespacing to avoid this and similar problems going forward. It hasn't been implemented despite crowd demanding it on HN for years because

> Rust crates need namespacing to avoid this and similar problems going forward. It hasn't been implemented despite crowd demanding it on HN for years because it won't solve the problem (namespace squatting is going to replace name squatting and tada! you're back to square one with an extra step).

Macha 2y ago
I do agree that people will assume xyz/xyz is more authoriative than some-org/xyz, but I think there is benefit to knowing that everything under xyz/* has a single owner. The current approach is to name companion crates like xyz_abc but someone else could come along with xyz_def and it's not immediately obvious that xyz_abc has the same owner as xyz but xyz_def does not.
- littlestymaar 2y ago
  This is a completely different topic though, and I think there's interest in shipping something like that. That's the main problem with “just add namespace FFS” discussions that come every other week: everyone has its own vision of what namespace should look like and what they are meant for, but nobody has ever taken the time to write an RFC with supporting arguments. In fact, people bring this mostly in ways that are related to name squatting (like right here) even though that's not a problem namespace can solve in the first place. It's magical thinking at its finest.
  - Macha 2y ago
    > nobody has ever taken the time to write an RFC with supporting arguments. https://rust-lang.github.io/rfcs/3243-packages-as-optional-namespaces.html https://rust-lang.github.io/rfcs/3243-packages-as-optional-n... https://github.com/rust-lang/rfcs/pull/3243 https://github.com/rust-lang/rfcs/pull/3243
    - littlestymaar 2y ago
      Exactly, this isn't about “default namespace”, this is the other feature which I said had support (didn't know the RFC had been merged though, thanks for pointing that out). This isn't the kind of namespace people say they want to prevent squatting.
Illniyar 2y ago
Solved the problem almost completely in npm. Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that. But once you know a namespace is owned by a company or project, you can know that everything under it is legit. Which solves the vast majority of squatting and impersonation problems. Also you know that everything under "node" for example is part of the language.
- eru 2y ago
  > Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that. There's a way to solve it partially: you can have a special part of your namespace tied to domains and require that eg com.google.some-package be signed by a certificate that can also sign some-package.google.com Of course, there's no guarantee that https://company.com https://company.com belongs to the company, but the public has already developed ways of coping with that. (I specifically suggest doing that only to part of your namespace, because you still want people to be able to upload packages without having to register a domain first.)
  - littlestymaar 2y ago
    That just makes package names harder to remember and type (and actually less secure as more prone to typosquatting and backdoors in seamingly harmless pull requests) for no benefit. Keep in mind that the majority of package by far don't come from companies in the first place, and requiring individual developers to have a domain of their own isn't particularly welcoming. It's going to be tons of complexity for zero actual benefit.
    - Philpax 2y ago
      One wonders if Bluesky's approach to usernames might one day inspire a future package manager in this direction: a GUID that is then aliased to a friendly (sub)domain through proof of ownership, with a default fallback domain for those without a domain (i.e. mypkg.crates.io vs mypkg.philpax.me)
dpcx 2y ago
php deals with this by using the username/organization name of a repository as the namespace name of packages. At least then you're having to squat something further up the food chain.
rapind 2y ago
There are problems it does solve though. It’s incomprehensible that we get so many new package managers that fail to learn from the bajillion that came before.
- littlestymaar 2y ago
  It actually learned and that's what makes cargo as good as it is (arguably the best of all that came before, and a source of inspiration for the ones that came after). But its authors rightly concluded that it's useless to expect to prevent name squatting by any technical mean!
preisschild 2y ago
Why not do it like go does and use the git hosting domain as a prefix (like github.com/org/project)?
- HappMacDonald 2y ago
  I recall in the Elm community there was a lot of hooplah around the package system aligning too much with a single repo provider (github) so that might be one disincentive there.
- azornathogron 2y ago
  It doesn't have to be git either - a few version control systems are supported. See https://go.dev/ref/mod#vcs https://go.dev/ref/mod#vcs And it doesn't have to be the direct domain+path of the repository, it can be some URL where you put a metadata file that points to the source repo.
- littlestymaar 2y ago
  How does it prevent squatting in any way?
  - preisschild 2y ago
    At least it makes it easy to see the difference between std / official packages (not prefixed) and others.
    - littlestymaar 2y ago
      It doesn't apply to Rust them because std doesn't need to appear in the Cargo.toml file in the first place.

Macha 2y ago

I do agree that people will assume xyz/xyz is more authoriative than some-org/xyz, but I think there is benefit to knowing that everything under xyz/* has a single owner. The current approach is to name companion crates like xyz_abc but someone else could come along with xyz_def and it's not immediately obvious that xyz_abc has the same owner as xyz but xyz_def does not.

littlestymaar 2y ago
This is a completely different topic though, and I think there's interest in shipping something like that. That's the main problem with “just add namespace FFS” discussions that come every other week: everyone has its own vision of what namespace should look like and what they are meant for, but nobody has ever taken the time to write an RFC with supporting arguments. In fact, people bring this mostly in ways that are related to name squatting (like right here) even though that's not a problem namespace can solve in the first place. It's magical thinking at its finest.
- Macha 2y ago
  > nobody has ever taken the time to write an RFC with supporting arguments. https://rust-lang.github.io/rfcs/3243-packages-as-optional-namespaces.html https://rust-lang.github.io/rfcs/3243-packages-as-optional-n... https://github.com/rust-lang/rfcs/pull/3243 https://github.com/rust-lang/rfcs/pull/3243
  - littlestymaar 2y ago
    Exactly, this isn't about “default namespace”, this is the other feature which I said had support (didn't know the RFC had been merged though, thanks for pointing that out). This isn't the kind of namespace people say they want to prevent squatting.

Illniyar 2y ago

Solved the problem almost completely in npm. Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that. But once you know a namespace is owned by a company or project, you can know that everything under it is legit. Which solves the vast majority of squatting and impersonation problems. Also you know that everything under "node" for example is part of the language.

eru 2y ago
> Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that. There's a way to solve it partially: you can have a special part of your namespace tied to domains and require that eg com.google.some-package be signed by a certificate that can also sign some-package.google.com Of course, there's no guarantee that https://company.com https://company.com belongs to the company, but the public has already developed ways of coping with that. (I specifically suggest doing that only to part of your namespace, because you still want people to be able to upload packages without having to register a domain first.)
- littlestymaar 2y ago
  That just makes package names harder to remember and type (and actually less secure as more prone to typosquatting and backdoors in seamingly harmless pull requests) for no benefit. Keep in mind that the majority of package by far don't come from companies in the first place, and requiring individual developers to have a domain of their own isn't particularly welcoming. It's going to be tons of complexity for zero actual benefit.
  - Philpax 2y ago
    One wonders if Bluesky's approach to usernames might one day inspire a future package manager in this direction: a GUID that is then aliased to a friendly (sub)domain through proof of ownership, with a default fallback domain for those without a domain (i.e. mypkg.crates.io vs mypkg.philpax.me)

dpcx 2y ago

php deals with this by using the username/organization name of a repository as the namespace name of packages. At least then you're having to squat something further up the food chain.

rapind 2y ago

There are problems it does solve though. It’s incomprehensible that we get so many new package managers that fail to learn from the bajillion that came before.

littlestymaar 2y ago
It actually learned and that's what makes cargo as good as it is (arguably the best of all that came before, and a source of inspiration for the ones that came after). But its authors rightly concluded that it's useless to expect to prevent name squatting by any technical mean!

preisschild 2y ago

Why not do it like go does and use the git hosting domain as a prefix (like github.com/org/project)?

HappMacDonald 2y ago
I recall in the Elm community there was a lot of hooplah around the package system aligning too much with a single repo provider (github) so that might be one disincentive there.
azornathogron 2y ago
It doesn't have to be git either - a few version control systems are supported. See https://go.dev/ref/mod#vcs https://go.dev/ref/mod#vcs And it doesn't have to be the direct domain+path of the repository, it can be some URL where you put a metadata file that points to the source repo.
littlestymaar 2y ago
How does it prevent squatting in any way?
- preisschild 2y ago
  At least it makes it easy to see the difference between std / official packages (not prefixed) and others.
  - littlestymaar 2y ago
    It doesn't apply to Rust them because std doesn't need to appear in the Cargo.toml file in the first place.