All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.

▲

saturn_vk an hour ago | parent | next [-]

IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable

	▲	matheusmoreira an hour ago \| parent [-]
		That changes nothing. If you're downloading packages pushed by randoms, then it's vulnerable. There is no escaping it. Go's module index is filled with people's GitHub repositories. You have no idea what's inside those things unless you review the source yourself.

▲

myaccountonhn an hour ago | parent | prev | next [-]

It's far far harder to do something exploits like this in elm because effects are tagged. There are solutions out there.

▲

CBLT 2 hours ago | parent | prev | next [-]

Eh, it's worse than that. The GP comment is repeating a joke derived from an Onion headline about gun control. Where the very poignant message is about political will to make change. However, the npm ecosystem is very much willing and has already made several changes. If we're going to engage in discussion instead of meme-posting, the GP should have (imo) included real commentary _in addition to_ the meme they really wanted to post. What is the policy they want? Why do they see the NPM ecosystem as still resistant to change?

▲

gbear605 2 hours ago | parent | next [-]

One easy change would be that before any package can be published, it has to wait a minimum of two weeks in a state where it can be reviewed but it can't be installed without jumping through several hoops with big warning signs, things like "INSTALL_INTENTIONALLY_DANGEROUS_PACKAGES_THAT_WILL_BREAK_MY_COMPUTER=1", selecting yes in a dialogue that asks if they want to install software that likely has viruses, and pointing to a different package repository URL.

If there's some change that must get out sooner, then there can be some fee to pay to npm to have their security team do their own review.

Critically, there must be time for someone to review before it's the default to be selected.

I'm sure there are issues with this, this was off my head, but it seems like a really easy step to at least stem the problem for now. And there are a bunch of ideas like this that would help, but NPM doesn't seem willing to take it seriously as an existential threat to the ecosystem, rather than taking trivial steps.

▲

matheusmoreira 2 hours ago | parent [-]

> where it can be reviewed

> Critically, there must be time for someone to review

By who? No one at npm is reviewing anything. "Someone" is doing a lot of work here.

Linux distributions have trusted maintainers who are responsible for their packages. People who cared enough to figure out PGP and set up an actual web of trust. That's where the verification happens. All these programming language package managers have nothing of the sort. PyPI, Rubygems, crates, npm, it doesn't matter. I can just make an account and push whatever I want.

These package managers are like this because that's what developers actually want. They don't want to deal with Linux distribution maintainers in order to get their software into the official repositories. They want to just run $packager push and have it out there with zero friction.

	▲	jruohonen 10 minutes ago \| parent [-]
		Indeed, my sentiment also, which I posted elsewhere: https://news.ycombinator.com/item?id=48358080

▲

jauntywundrkind 2 hours ago | parent | prev [-]

They didn't back up their meme with real commentary because they have no real commentary to stand on:

They're spreading cheap disdain & scorn for npm ("only package manager" framing). But most other package management systems have similar abilities to run pretty un-sandboxed code.

TrapDoor has hit python, rust, and js repos. https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra...

▲

throwwwll 2 hours ago | parent | prev | next [-]

Nix enters the room.

(Everyone claps.)

▲

ajross 2 hours ago | parent | prev | next [-]

While true, tarring Arch here is a little unfair. AUR isn't enabled by default. It can't even be used via the same package front end, and in fact the "official" usage model requires that you clone the source yourself.

Indeed, AUR is bad as a software distribution mechanism (really it's best understood as a proving ground for baby packages before they get real maintainers and distro blessing), but it's less bad than NPM which puts the malware in the trusted/default/automated path.

▲

matheusmoreira 2 hours ago | parent | next [-]

I'm not tarring Arch, I was praising it. I made sure to explicitly spell out the "User Repository". Arch is the one that does it right.

▲

Ancapistani 2 hours ago | parent | prev [-]

I didn’t take it that way at all - rather, Arch is the only one that does it “right” with the AUR.

▲

nailer 2 hours ago | parent [-]

If you want a usable system, you enable AUR. It's not 'doing it right', it's avoiding responsibility.

	▲	antiframe an hour ago \| parent [-]
		Depends on who 'you' are. I have one package I installed from the AUR and it's from a corporation that just repackages their builds. The problem is always who vets the packages. I trust the Arch team and I trust that one corporation. Also to use the AUR it's a different command, so I can't get surprised by an AUR package. It's not a pacman -Syu is going to pull in a new unknown to me AUR package.

▲

the__alchemist 2 hours ago | parent | prev [-]

I think this is a thought-terminating cliche, and false equivalences. Stating "This area where problems occur at a high rate is not a problem, as problems can happen elsewhere too" is a curt dismissal of a valid concern. It implies the course of action, rather than to address a high-problem area, is to ignore any solutions which aren't global, or equate it to lower-incidence areas.

You bring up a good point that this class of problem, or related ones can occur with other package managers. It was frustrating how long it took the Crates.io team (Rust manager) to address name squatting, in what appeared to be a "no perfect solution exists, so we won't act" line of reasoning.

	▲	matheusmoreira 2 hours ago \| parent \| next [-]
		It was a reply to "only package manager where this regularly happens". Anyone who thinks it can't happen to them just because they're writing Python instead of Javascript is in for a world of hurt. The comment I replied to is a literal meme. That's as charitable as it gets. Nothing "thought-terminating" about it.
	▲	kalcode 2 hours ago \| parent \| prev [-]
		It's the exact same logic people used for Apple computers back in the day. The idea that Macs didn't get viruses because they were inherently more secure. But that wasn't true. It was purely a numbers game. Windows' popularity was so far off the charts that hackers naturally targeted Windows users instead of Mac users; it was just a better use of their time. The same thing is happening here. Other package managers do get compromised, but the sheer frequency of npm incidents just reflects how overwhelmingly popular Node.js and web apps are right now. JavaScript simply has a much higher usage rate than most other languages.