11 ms·

I'm surprised the reverse fully-qualified domain name (FQDN) model used by Java isn't more widely adopted. If you want to upload artifacts to the main repositor

I'm surprised the reverse fully-qualified domain name (FQDN) model used by Java isn't more widely adopted. If you want to upload artifacts to the main repository (Maven Central) you first need to show ownership of a particular domain. For example, via a DNS TXT record (example [1]). Would make these kind of attacks a lot more difficult. [1] https://issues.sonatype.org/browse/OSSRH-61509 https://issues.sonatype.org/browse/OSSRH-61509

numpad0 6y ago
because without proper incentive mechanism people just use "com.mycompany.greatproduct12345" for everything
tarruda 6y ago
It seems some of the new package systems such as node/npm fail to learn from years of maturity of existing ecosystem such as Java's
- raverbashing 6y ago
  "Years of maturity" or, just thinking about the problem for a bit. How long did it take npm to have scoped packages. Sure, let me create a "paypal" project, they only need one js project no? If Java suffers from excessive bureaucracy, the newer package developers/repos suffer from too much eagerness to ship something without thinking Not to mention dependency and version craziness. If you want your software to be repeatable you need to be specific with the versions and code you're taking.
  - mstipetic 6y ago
    It drives me crazy that "official" sounding package names like yaml are seemingly given basically first-come first serve, with no oversight. Publish anything you want, but call it Mark's awesome yaml library, or companyName-yaml or something like that so that people are aware that's not an officially supported project
    - jrochkind1 6y ago
      What would you imagine that oversight looking like, who decides who gets the name `yaml`, and how do they verify it, and who pays for that time?
      - throw_m239339 6y ago
        > What would you imagine that oversight looking like, who decides who gets the name `yaml`, and how do they verify it, and who pays for that time? Just use name spaces. foo.com/yaml instead of yaml. NPM way of doing things is/was just insane, with no regard for trust or security. No wonder NPM corp then went into the business of selling namespaces, AKA selling trust...
      - mstipetic 6y ago
        Unless it's a part of the standard library included with the language, nobody gets it. There has to be some designation before the name. It's not only node, python also does things like that
        jrochkind1 6y ago
        I don't understand how a designation in front of the name solves anything. The designation is basically just a name itself, you've just made it a two-part name, and a requirement that all names have two parts. ok, so?
        saagarjha 6y ago
        The first part is going to be your name.
- deleted 6y ago
  [deleted]
- ratherbefuddled 6y ago
  As someone who worked with java for more than a decade before touching the js world, the degree to which npm has been hacked together without any of study prior art is extremely irritating. If you must build something from scratch at least invent some new problems instead of just re-discovering solved ones. The very existence of package-lock grinds my gears and that's before it starts flip flopping because someone mistook URLs for URIs. Of course that only exists because ranged dependencies are a terrible idea, and that's before anybody even mentions things like namespaces or classifiers. No maven wasn't perfection, and it could be (and has been) improved on - but npm doesn't even get into spitting distance.
Aissen 6y ago
Or the URL-based model used by Go.
- SideburnsOfDoom 6y ago
  What does the url model bring? Packages are typically considered immutable once published. If I have a particular package e.g. "FooLib.Bar v 1.2.3" then this zip file should _always_ contain the same bits. If I need to change those bits, e.g. to fix a bug then I need to ship e.g. "FooLib.Bar v 1.2.4" Also packages aren't always small. So it makes sense to cache a copy locally. On dev machine "package cache" and in an org's "internal feed" and only check upstream if it's not there. So I shouldn't need to go to the source url to get it. Ideally, I just ask "who has "FooLib.Bar v 1.2.3" for me?" It also means that tampering can be detected with a hash. But the "check upstream" model is now vulnerable to fake new versions.
  - mythz 6y ago
    Using a FQDN is less likely to be unknowingly hijacked when it's a domain they control and use daily. URL references also contain the version number, typically an immutable Git tag reference. They also benefit from just needing to download the source code that's referenced and not the entire package. With Deno you can also optionally host versioned 3rd Party packages on their deno.land/x CDN. URL references are also cached locally on first use and can be used offline thereafter.
  - michaelt 6y ago
    For better or for worse, many projects auto-update their dependencies these days. They do this to address the shortfalls of modern conventions like small packages, continuous release cycles and dependencies nested several layers deep. So if you were using the internal package FooLib.Bar v 1.2.3 and an attacker posts FooLib.Bar v 1.2.4 to a global repository, anyone using auto-updating will update to it.
    - SideburnsOfDoom 6y ago
      I don't disagree, but both of these (fully or partly automated updates, and attackers) are fairly recent developments to the model. Of course, mitigation is needed. Supply chain attacks are a hot topic after SolarWinds. But identifying a package version solely by a url doesn't seem like the right abstraction to me. IMHO, the metadata is more structured: Name (text), version (SemVer) and also maybe now fields to verify and mitigate these attacks: content hash, source feed, etc. Even if I run an internal feed that transparently proxies and caches the public one, as well as hosting my company's internal artefacts, the rules now might need to be different between packages? for e.g. between Newtonsoft.Json (new versions always originate on the public feed, never locally) and "SDCo.GeneralUtils" (new versions always originate on the local feed, never upstream)
jeswin 6y ago
Javas FQDN model is actually pretty bad in practice. Domain names change quite often (I've seen many packages with a dead FQDN), and relying on the TXT record is going to be a security nightmare even worse than the username/password required by npm (since domains expire).
- kasperni 6y ago
  You only need to validate the domain once using a TXT record. And then you use another authentication mechanism such as a username/password combination.
- brabel 6y ago
  > Javas FQDN model is actually pretty bad in practice Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... oh, wait?! NO! The kind of simple attacks you see routinely on npm (typo squatting, ownership transfers to malicious authors, now this) just doesn't happen on Maven Central at all.
  - littlestymaar 6y ago
    > Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... Oh yes, the differences is necessarily explained by Maven design being better, and absolutely not because there are two orders of magnitude difference in usage between these two systems… There are supply chain attacks in Maven Central too[1], but it's not gonna make the front page of HN… [1] a quick ddg search, just last month https://securityboulevard.com/2021/01/sonatype-stops-software-supply-chain-attack-aimed-at-the-java-developer-community/ https://securityboulevard.com/2021/01/sonatype-stops-softwar...
    - syjer 6y ago
      You may notice that in the linked article, only the artifact id has been spoofed. In maven you need to declare both groupId and artifactId for your dependency (and a fixed version, a range is generally considered a bad practice). To be noted, it makes this kind of attack more difficult, but not impossibile. Especially the mix public/private artifacts. I guess it will force a lot of companies to at least lock their groupId on maven central, if they never bothered to do so.
kevinherron 6y ago
Hmm, I wonder when this policy started. I did not have to prove ownership of the domains for the coordinates I use, though I do happen to own them.

numpad0 6y ago

because without proper incentive mechanism people just use "com.mycompany.greatproduct12345" for everything

tarruda 6y ago

It seems some of the new package systems such as node/npm fail to learn from years of maturity of existing ecosystem such as Java's

raverbashing 6y ago
"Years of maturity" or, just thinking about the problem for a bit. How long did it take npm to have scoped packages. Sure, let me create a "paypal" project, they only need one js project no? If Java suffers from excessive bureaucracy, the newer package developers/repos suffer from too much eagerness to ship something without thinking Not to mention dependency and version craziness. If you want your software to be repeatable you need to be specific with the versions and code you're taking.
- mstipetic 6y ago
  It drives me crazy that "official" sounding package names like yaml are seemingly given basically first-come first serve, with no oversight. Publish anything you want, but call it Mark's awesome yaml library, or companyName-yaml or something like that so that people are aware that's not an officially supported project
  - jrochkind1 6y ago
    What would you imagine that oversight looking like, who decides who gets the name `yaml`, and how do they verify it, and who pays for that time?
    - throw_m239339 6y ago
      > What would you imagine that oversight looking like, who decides who gets the name `yaml`, and how do they verify it, and who pays for that time? Just use name spaces. foo.com/yaml instead of yaml. NPM way of doing things is/was just insane, with no regard for trust or security. No wonder NPM corp then went into the business of selling namespaces, AKA selling trust...
    - mstipetic 6y ago
      Unless it's a part of the standard library included with the language, nobody gets it. There has to be some designation before the name. It's not only node, python also does things like that
      - jrochkind1 6y ago
        I don't understand how a designation in front of the name solves anything. The designation is basically just a name itself, you've just made it a two-part name, and a requirement that all names have two parts. ok, so?
        saagarjha 6y ago
        The first part is going to be your name.
deleted 6y ago
[deleted]
ratherbefuddled 6y ago
As someone who worked with java for more than a decade before touching the js world, the degree to which npm has been hacked together without any of study prior art is extremely irritating. If you must build something from scratch at least invent some new problems instead of just re-discovering solved ones. The very existence of package-lock grinds my gears and that's before it starts flip flopping because someone mistook URLs for URIs. Of course that only exists because ranged dependencies are a terrible idea, and that's before anybody even mentions things like namespaces or classifiers. No maven wasn't perfection, and it could be (and has been) improved on - but npm doesn't even get into spitting distance.

Aissen 6y ago

Or the URL-based model used by Go.

SideburnsOfDoom 6y ago
What does the url model bring? Packages are typically considered immutable once published. If I have a particular package e.g. "FooLib.Bar v 1.2.3" then this zip file should _always_ contain the same bits. If I need to change those bits, e.g. to fix a bug then I need to ship e.g. "FooLib.Bar v 1.2.4" Also packages aren't always small. So it makes sense to cache a copy locally. On dev machine "package cache" and in an org's "internal feed" and only check upstream if it's not there. So I shouldn't need to go to the source url to get it. Ideally, I just ask "who has "FooLib.Bar v 1.2.3" for me?" It also means that tampering can be detected with a hash. But the "check upstream" model is now vulnerable to fake new versions.
- mythz 6y ago
  Using a FQDN is less likely to be unknowingly hijacked when it's a domain they control and use daily. URL references also contain the version number, typically an immutable Git tag reference. They also benefit from just needing to download the source code that's referenced and not the entire package. With Deno you can also optionally host versioned 3rd Party packages on their deno.land/x CDN. URL references are also cached locally on first use and can be used offline thereafter.
- michaelt 6y ago
  For better or for worse, many projects auto-update their dependencies these days. They do this to address the shortfalls of modern conventions like small packages, continuous release cycles and dependencies nested several layers deep. So if you were using the internal package FooLib.Bar v 1.2.3 and an attacker posts FooLib.Bar v 1.2.4 to a global repository, anyone using auto-updating will update to it.
  - SideburnsOfDoom 6y ago
    I don't disagree, but both of these (fully or partly automated updates, and attackers) are fairly recent developments to the model. Of course, mitigation is needed. Supply chain attacks are a hot topic after SolarWinds. But identifying a package version solely by a url doesn't seem like the right abstraction to me. IMHO, the metadata is more structured: Name (text), version (SemVer) and also maybe now fields to verify and mitigate these attacks: content hash, source feed, etc. Even if I run an internal feed that transparently proxies and caches the public one, as well as hosting my company's internal artefacts, the rules now might need to be different between packages? for e.g. between Newtonsoft.Json (new versions always originate on the public feed, never locally) and "SDCo.GeneralUtils" (new versions always originate on the local feed, never upstream)

jeswin 6y ago

Javas FQDN model is actually pretty bad in practice. Domain names change quite often (I've seen many packages with a dead FQDN), and relying on the TXT record is going to be a security nightmare even worse than the username/password required by npm (since domains expire).

kasperni 6y ago
You only need to validate the domain once using a TXT record. And then you use another authentication mechanism such as a username/password combination.
brabel 6y ago
> Javas FQDN model is actually pretty bad in practice Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... oh, wait?! NO! The kind of simple attacks you see routinely on npm (typo squatting, ownership transfers to malicious authors, now this) just doesn't happen on Maven Central at all.
- littlestymaar 6y ago
  > Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... Oh yes, the differences is necessarily explained by Maven design being better, and absolutely not because there are two orders of magnitude difference in usage between these two systems… There are supply chain attacks in Maven Central too[1], but it's not gonna make the front page of HN… [1] a quick ddg search, just last month https://securityboulevard.com/2021/01/sonatype-stops-software-supply-chain-attack-aimed-at-the-java-developer-community/ https://securityboulevard.com/2021/01/sonatype-stops-softwar...
  - syjer 6y ago
    You may notice that in the linked article, only the artifact id has been spoofed. In maven you need to declare both groupId and artifactId for your dependency (and a fixed version, a range is generally considered a bad practice). To be noted, it makes this kind of attack more difficult, but not impossibile. Especially the mix public/private artifacts. I guess it will force a lot of companies to at least lock their groupId on maven central, if they never bothered to do so.

kevinherron 6y ago

Hmm, I wonder when this policy started. I did not have to prove ownership of the domains for the coordinates I use, though I do happen to own them.