Hacker News Reader

Comment by renewiltord | Hacker News Reader

These are some good differences. Personally, the one thing I do miss from the modern package managers is the Java-style namespacing that piggy-backs on DNS. I wonder if there is some project out there that has decided to piggy-back on ENS namespacing. And then you can have eth.renewiltord and have your packages under that, and then when your projects are all quite established, your ENS domain will have a public value that matches the exploit surface if someone were to get it. And then you can sell it and reap the rewards of EEEEVIL!

View on HN

As much as it can be annoying to type out those imports in Java, I agree.

All the "first one who asks for the name gets it" package managers suffer from problems (some of them security-related) that anything that talks to Maven Central does not.

If you want an account on Sonatype's OSS repository (which allows you to push to Maven Central), you need to prove that you have control of the domain you want to use (in reversed form) as the "group ID" you publish libraries under (IIRC, by setting a TXT record in DNS). Meanwhile, to publish to crates.io, you just link your GitHub account (which is required, gross), and then you can publish to any package name that hasn't yet been taken, and then it's yours, forever. That seems terrible, somehow.

(Granted, that just covers the group ID for depending on the library; you can put Java classes in that library wherever you want, even in "other people's" namespaces. In practice, though, I don't think this ends up being a big issue.)

(Also granted, if you let your domain registration lapse, someone else could snap it up and possibly hijack your namespace. But I wouldn't be surprised if the Sonatype folks would try to get in touch with you if someone else tried to claim your namespace, even if they had control over the domain.)

I worked for many years in the enterprise java world, and when I went to do other things I was surprised how bad or incomplete package management is in other language ecosystems. The maven packaging system (as distinct from the Maven tool itself) makes managing dependencies for building and shipping java applications much more sane.

To reiterate the point on the Maven packaging system vs. the Maven tool itself:

All the post-Maven build automation tools in the JVM world, including Gradle, Apache Ivy, and sbt (the Scala build tool) use Maven repositories.

Good package index sites give you the syntax to grab the package in your tool of choice, for example (click the tabs):

https://mvnrepository.com/artifact/org.apache.commons/common...

Gatekeeping people from publishing crates behind owning a domain will never work in the Rust ecosystem.

Plenty of com.github.xyz -packages in Java.

c.f. https://jitpack.io/

They don't need to "own" anything. They can just use Github pages or any free subdomain in this entire universe.

If you can't be bothered to set up a free account in 5 minutes somewhere, how valuable or trustworthy is your library, really?

> Personally, the one thing I do miss from the modern package managers is the Java-style namespacing that piggy-backs on DNS.

Though it's not directly apparent, I would say that cargo (and probably some other package managers) actually does that. It just also does a really good job of hiding that in the default cause where all your dependencies come from crates.io.

For every dependency, the source registry is also recorded, so the full package id is a concatenation of roughly "source registry URL + package name + package version". So if one were really interested in having bigger reliance on DNS to establish namespacing, one could utilize many different registries.

In practice, there are however good reasons related to supply chain security why you probably don't want to do that. E.g. domain names changing ownership adds a whole new attack surface that you need to secure against.

You can (almost) always set up different registries, this is not what GP is talking about. Java packages are named according to (reversed) domain names, e.g. the standard library is in net.java.*, and Java registries allow/require you to prove you own the corresponding domain (Let's Encrypt-style) using a DNS record before publishing a package.

Right, but suppose I depend on the org.example.foo package today, and next month someone else buys the example.org domain specifically so that they can insert their malicious code into the foo package?

Domain names simply do not eliminate supply–chain problems, they only make your packaging system dependent on DNS.

That's still a lot harder and more visible than just taking over an orphaned package or many of the other attacks we see in these other ecosystems.

Especially since DNS gives you real visibility into ownership when auditing/selecting packages.

org.apache is a lot more trustworthy than tk.helicopter.

Never understood why people didn't steal this idea to eliminate typosquatting and "all the cool names" squatting.

>modern package managers is the Java-style namespacing that piggy-backs on DNS.

Doesn't Go kind of do this by having things be git repo address? It's not hierarchical, but it is tied to something "real world"

Yes. I kinda like this solution but I am wary of tying a language ecosystem to any particular version–control system, even one so nice and ubiquitous as Git.

Couldn't we just use git::github.com/foo/bar or so?

Reply on news.ycombinator.com