[1propionyl]

> I can't help but wonder if the root cause was HTTP request smuggling, or if changing package.json was enough.

Maybe I'm just incredibly cynical from my experiences with the intersection of the JS ecosystem and security, but...

...I'd bet dimes to dollars it's the latter (just changing the package.json). My guess is they authenticate but don't actually scope the authentication properly, and no one noticed because no one thought to look.

Of course, as we've seen in the past decade, there's so much inertia behind the JavaScript ecosystem that none of this is going to fundamentally change. It'll just take another decade or so for the ecosystem to reinvent all of the wheels and catch up to the rest of the space.

And at that point it will probably be considered stuffy and "enterprise" and the new hotness unburdened from such concerns will repeat the cycle again.

[mhio]

> to reinvent all of the wheels and catch up to the rest of the space.

Which of the public package systems are the state of the art that should be replicated?

[chakkepolja]

The 'wheels' might simply be having a standard library and less number of packages instead of micropackage mess.

For example, look at django, it provides more functionality (though not directly comparable to) than react. But installation is quick and there are small number of packages from trusted authors.

The ecosystem is orthogonal to how good package manager is.

[thrashh]

Java’s works really well.

I think it makes other package managers look like a toy.

[mhio]

I assume you are referring to Apache Maven tooling (and compatible) and the pom repos, like Sonatype's Central Repo.

PGP package signing is a huge plus. Is that a requirement for publishing?

How many different repo's do you typically have to deal with in the average project?

Would Sonatype react quickly to malware issue's like this in the repository? Have there been examples of similar package hijacking?

[thrashh]

It’s a requirement for the central repo if I recall.

And the best past is the signature handling is a part of Java, not the package manager, so nothing needs to be re-invented. The default class loader checks the signatures at runtime as well.

Typically you need 1-2 repositories, but often just 1. But if you’re an organization, you can set up your own repository very easily and use it to store private deps and to cache deps (which also allows you to lock binaries and work offline). Repo mirroring is super easy to set up. If you have an internal repo, you can just have your internal project use your own repo and your computer never has to directly reach outside the Internet for a package.

Unlike other languages, the “central repo” and the package manager tooling are independent and package resolution is distributed. When you start a project, you choose your repos. I don’t know how quickly Sonatype would react personally but they are only default by de facto. Many packages are published on several repos and mirroring is a default feature of a lot of repo software. If Sonatype started screwing up, everyone could abandon them instantly, which forces them to be better.