3 ms·

> 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

> 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.

deredede 4y ago
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.
- db48x 4y ago
  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.
  - oblio 4y ago
    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.

deredede 4y ago

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.

db48x 4y ago
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.
- oblio 4y ago
  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.