3 ms·

All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintaine

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.

the__alchemist 5mo ago
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.
- kalcode 5mo ago
  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.
- matheusmoreira 5mo ago
  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.
ajross 5mo ago
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.
- Ancapistani 5mo ago
  I didn’t take it that way at all - rather, Arch is the only one that does it “right” with the AUR.
  - nailer 5mo ago
    If you want a usable system, you enable AUR. It's not 'doing it right', it's avoiding responsibility.
    - antiframe 5mo ago
      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.
    - Ancapistani 5mo ago
      It's putting the responsibility on the party most capable and interested in evaluating the packages for security.
- matheusmoreira 5mo ago
  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.
CBLT 5mo ago
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?
- jauntywundrkind 5mo ago
  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-crates https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra...
- gbear605 5mo ago
  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 5mo ago
    > 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.
throwwwll 5mo ago
Nix enters the room. (Everyone claps.)
myaccountonhn 5mo ago
It's far far harder to do something exploits like this in elm because effects are tagged. There are solutions out there.
saturn_vk 5mo ago
IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable
- matheusmoreira 5mo ago
  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.
- gus_ 5mo ago
  https://www.reddit.com/r/neovim/comments/1j45stl/someone_wrote_malicious_code_in_the_neovim_plugin/ https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...

the__alchemist 5mo ago

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.

kalcode 5mo ago
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.
matheusmoreira 5mo ago
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.

ajross 5mo ago

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.

Ancapistani 5mo ago
I didn’t take it that way at all - rather, Arch is the only one that does it “right” with the AUR.
- nailer 5mo ago
  If you want a usable system, you enable AUR. It's not 'doing it right', it's avoiding responsibility.
  - antiframe 5mo ago
    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.
  - Ancapistani 5mo ago
    It's putting the responsibility on the party most capable and interested in evaluating the packages for security.
matheusmoreira 5mo ago
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.

CBLT 5mo ago

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?

jauntywundrkind 5mo ago
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-crates https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra...
gbear605 5mo ago
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 5mo ago
  > 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.

throwwwll 5mo ago

Nix enters the room. (Everyone claps.)

myaccountonhn 5mo ago

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

saturn_vk 5mo ago

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

matheusmoreira 5mo ago
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.
gus_ 5mo ago
https://www.reddit.com/r/neovim/comments/1j45stl/someone_wrote_malicious_code_in_the_neovim_plugin/ https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...