Hacker News Reader

Comment by kelnos | Hacker News Reader

While the Java ecosystem tends to get a lot of criticism, this is one thing they got right: fetching a package name from a public repository involves prefixing the name with the reverse-DNS name of the uploader (the "group ID" in Java/maven parlance). Uploaders can only submit packages after they've proven they have control over the domain.

It's really unfortunate that even newer package management ecosystems like Rust's haven't learned that lesson. Yes, it increases initial setup friction, but dependency confusion and name squatting issues more or less just go away when you do that. Sure, you might run into issues where people register domains for common misspellings of popular domain names, but that's already a problem with website resolution, and there are ways to mitigate that.

View on HN

The problem described in the post isn't the fault of package naming schemes, it's due to `pip install --extra-index-url` apparently ignoring the user-specified registry if the package exists on PyPI, which, if true, is baffling, because it throws out the concept of private registries altogether in favor of treating PyPI as some sort of universal namespace.

> due to `pip install --extra-index-url` apparently ignoring the user-specified registry if the package exists on PyPI

I thought this was the expected behavior of --extra-index-url

To force pip to use a user-specified registry, you would use --index-url instead of --extra-index-url

We ran into a pretty serious vulnerability around editable installs last year as well. Nearly the same story as here - basically an editable install hit an edge case and went to pypi instead when you wouldn’t expect it to. Python has not thought this problem through nearly as much as the Java people have.

> The problem described in the post isn't the fault of package naming schemes

If PyPI used Java-like scheme with domain ownership verification, Google would presumably use com.google.* namespace for their private stuff and it wouldn’t be possible to introduce malicious package this way.

So the described issue arguably is a consequence of that.

That Github issue is insane. So frustrating that an obviously wrong behavior is continued even after exploits in the wild. Count me as one of those idiot users who was confused by the current behavior.

To be fair, the parameter is called extra index url, not private index url.

That there is no other option for private repositories or namespacing is still a big shame.

There is, as already pointed out in a sibling comment, and it's called --index-url: https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-0

What happens in the Java ecosystem when someone loses ownership of their domain name?

nothing immediately, once your account has the namespace it keeps it.

I don't know the policies on what would happen if someone else registered the domain and contested the ownership though.

Someone who can't bother to pay a $10 renewal fee for a domain probably isn't maintaining that package either.

That’s just silly. Suppose someone doesn’t want to maintain a package any longer, retires or dies?

I think the implication here is that you probably shouldn't be using unmaintained packages. I guess you can at your own risk.

I challenge you to audit all dependencies and, particularly, the sub-dependencies of those. Most people, in my experience, look at a requirements.txt or package.json and think that’s everything but your dependency tree is going to be easily 3-4x that size.

Node.js is particularly notorious for this. It’s a big challenge for having non-flat dependency management and there’s no great solution for this problem.

Well, I don't use Node.js and I'm careful about cargo dependencies, so I actually can do this with every project I have worked on, and I value the ability to do it. It has led to a lot more sleep, as I understand it, than people with critical projects that rely on npm get. Cargo doesn't exactly have the all of the problems that npm has, but it is already kind of time consuming to audit your dependencies in Rust.

Sure, you can do it. But, have you? I'm betting not, and I think that's the point.

Maybe they cannot legally hold it anymore? For instance, I believe that UK citizens are no longer eligible for .eu

As in all things, it breaks. There is no magic bullet. Period.

Domain ownership is only needed to claim the group ID in the first place. After that it's associated with your account.

Pinning to a private key could help. Admittedly not a magic bullet.

I think this is primarily something from maven central. No technical limitation in maven.

FWIW, I've seen discussions on the topic in the Rust community. No guarantee that it's going to happen, but at least people are aware of the issue.

Especially since a few users slurped up all of the interesting package names and refuse to give them up, despite many people complaining on GitHub. It's one of the huge warts of the cargo ecosystem it seems nobody on the rust team is willing to fix.

I think all packages should be namespaced per user. The language's core team could promote widely used packages to a "standard" namespace and give it a good name that way, thereby making it the "canonical" implementation of something.

I dunno how ecosystems keep making the same mistake.

All so someone can save few letters with typing dep name that one time they will be pulling it in into their project

The lack of namespacing in Rust is so weird. The discussion has been going for years, but it makes zero sense to me that after seeing issues npm and pypi faced during the past decade Rust is still pushing back against a more structured registry structure. Squatting will become more and more problematic the longer this flat registry approach persists.

Not only do they refuse to fix it, every time I've brought it up, they insist it isn't a mistake, and this way is better than, or no worse than, what Java does.

Who do you think slurped up the package names? It's not going to be random people.

This punk: https://crates.io/users/swmon

They aren’t the only one, but they’re… prolific in this area. A list of squatted names is maintained here: https://github.com/dtolnay/squatternaut

They didn't get it that right (as the other dude said - it's server side security by the service provider).

Requiring that third party dependencies be signed should have been the default in Maven itself.

the reversed DNS name part is a bit silly tho

Can you elaborate what is silly about it? The reversing, or the DNS, or both?

A package called com.example.foo would be package foo in the namespace "example", which is under the namespace "com", which is how a lot of languages do namespace nesting.

DNS can be said to be "reversed" from that point of view.

Why? Because you don't like it?

Chesterton's fence.

It's all part of Java's effort to make everything as complicated as possible and put everything in as many namespaces as possible.

> While the Java ecosystem tends to get a lot of criticism, this is one thing they got right: fetching a package name from a public repository involves prefixing the name with the reverse-DNS name of the uploader (the "group ID" in Java/maven parlance). Uploaders can only submit packages after they've proven they have control over the domain.

That doesn't really solve the fundamental problem, though. Domains can and do change hands by various means and for various reasons having little to do with Java packaging, meaning that control of those packages can be transferred as well. It's just shifting the problem to a different place is all.

I'm not registering a domain just to publish a package. No wonder Java is a hellscape.

You can use io.github.youruser or any other meriod of namespaces you can get for free

Reply on news.ycombinator.com