Remix.run Logo
Illniyar 5 days 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 5 days ago | parent [-]

> 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 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 4 days ago | parent [-]

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 4 days ago | parent | next [-]

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)

eru 2 days ago | parent | prev [-]

> [...], and requiring individual developers to have a domain of their own isn't particularly welcoming.

Try reading my comment.

I specifically said that this shouldn't be required, and would only apply to one part of the namespace.