6 ms·

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia

by jofzar 4mo ago

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

matheusmoreira 4mo ago
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 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
    I didn’t take it that way at all - rather, Arch is the only one that does it “right” with the AUR.
    - nailer 4mo ago
      If you want a usable system, you enable AUR. It's not 'doing it right', it's avoiding responsibility.
      - antiframe 4mo 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 4mo ago
        It's putting the responsibility on the party most capable and interested in evaluating the packages for security.
  - matheusmoreira 4mo 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 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
  Nix enters the room. (Everyone claps.)
- myaccountonhn 4mo 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 4mo ago
  IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable
  - matheusmoreira 4mo 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_ 4mo 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...
chuckadams 4mo ago
The big attacks of today are spread across several package ecosystems: TrapDoor and Shai-Hulud have been hitting npm, pypi, composer, and crates with the same malware.
- throwwwll 4mo ago
  And all of them "thought" of security as an after-after-after-after-after-thought.
  - deleted 4mo ago
    [deleted]
  - freakynit 4mo ago
    Most of these are now building upon techniques that have already been exploited since past 1 years. This attack used 4 of those techniques. 1. Lifecycle Hook Execution 2. CI/CD Identity Plane Attacks 3. Maintainer Account Takeover and Malicious Publish 4. Self-Replicating npm Worms https://npm-supply-chain-attack-techniques.pagey.site/ https://npm-supply-chain-attack-techniques.pagey.site/
    - throwwwll 4mo ago
      Regardless of what these attacks exploit, see elsewhere a larping comment of mine: the solution exists, the implementation already mitigated numerous such and other exploits (it's nice to read "nix is not affected" on discourse or over matrix chat), it predates Docker by a decade, and is older than Ubuntu and Fedora (to give the perspective), yet people prefer to remain ignorant.
      - zitterbewegung 4mo ago
        You can have a security solution but with large ecosystems like this it can’t be pushed to the ecosystem immediately and everyone will take longer to test and deploy. Right now you could audit packages and make sure you don’t get the latest version
ajross 4mo ago
PyPI and Cargo are, 100%, vulnerable to this same class of compromises. That NPM sucks isn't a statement that everyone else doesn't.
kalcode 4mo ago
People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.
- Defletter 4mo ago
  The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.
  - kalcode 4mo ago
    That's a good point. For me it's getting people to realize they need to take up practice that help minimize these things. It's kinda us and them problem. We need to ensure we don't just blindly install the latest, patch every CVE by just bumping everything to the latest even if the vulnerability has nothing to do with their system or use of said library. We should have rules that we install the latest that's older than three days. We should be running "npm audit" and other stuff like Trivy. The three day rule alone could save most people.
    - thaumasiotes 4mo ago
      > The three day rule alone could save most people. The three day 'rule' is just you hoping that someone else does some free work for you. If it is adopted by everyone, it has zero effect. We need rules that still work if people follow them.
      - deleted 4mo ago
        [deleted]
  - Kuinox 4mo ago
    nuget have targets, and allow to run code on build, it doesn't have this problem because there is less dependencies.
Someone1234 4mo ago
Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of other security settings, like minimum age, no trust downgrade, etc etc. All attackers can attack packages by updating how a package functions; but npm is particularly problematic as it runs non-sandbox scripts as the calling user. Putting not just your project at risk, but your entire machine/network. And this stuff has been known about for YEARS, they've taken no action.
- dns_snek 4mo ago
  > since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. This is semi-common and in no way unique to NPM.
  - Ajedi32 4mo ago
    And even in the ones that don't, having to wait until the project executes to begin its attack is a minor inconvenience for malware.
  - an0malous 4mo ago
    What other package managers do this? I don’t think Ruby does
    - matheusmoreira 4mo ago
      https://docs.ruby-lang.org/en//master/Gem.html#method-c-post_install https://docs.ruby-lang.org/en//master/Gem.html#method-c-post...
    - IshKebab 4mo ago
      Python does too I believe. Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly. The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it obviously.
TZubiri 4mo ago
tbf this is happening with a lot of package managers now, including pypi and composer
deleted 4mo ago
[deleted]
junon 4mo ago
Please stop posting this on every single security incident thread with npm. It was funny once, it's just rehashing the same debate over and over.
- da_chicken 4mo ago
  On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.
- chipdale 4mo ago
  Why should they stop? Maybe they want to rehash the issue that's not being adequately addressed. Maybe it's not supposed to be funny. How do you propose we address this issue? Instead of policing what people say, are you interested in sharing your or someone else ideas?
  - junon 4mo ago
    It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.
    - moi2388 4mo ago
      [flagged]
      - junon 4mo ago
        HN has guidelines about curious discussion. Read them.
- rectang 4mo ago
  Opponents of gun control surely feel the same way about the Onion’s story.
nailer 4mo ago
I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't allow scripts, but exploits happen everywhere.
- m4rtink 4mo ago
  If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution. Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack. Definitely not bulletproof but still IMHO more robust than "Lets just spray latest code from upstream without any review directly to production with a firehose!" that seems to be the norm.
  - cozzyd 4mo ago
    Yes and typically updates take a while to be deployed...
  - isityettime 4mo ago
    Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it. But there are norms in the distro about what those scripts are for and how to use them, and there's some social enforcement around that. The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of the social enforcement mechanisms are there and the companies behind the products I just mentioned all have histories of abusing them. That's why it's generally better to use Flatpak for things like that if your distro itself doesn't include them.
    - nailer 4mo ago
latexr 4mo ago
There’s actually a blog post with that exact title. https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://news.ycombinator.com/item?id=48155690 https://news.ycombinator.com/item?id=48155690
paulddraper 4mo ago
Last 30 days: PyPI, May 11. [1] Crates.io, May 22 [2] Composer, May 22 [3] [1] https://www.tenable.com/blog/mini-shai-hulud-frequently-asked-questions https://www.tenable.com/blog/mini-shai-hulud-frequently-aske... [2] https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-crates https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra... [3] https://phoenix.security/laravel-lang-composer-supply-chain-compromise-rce-backdoor/ https://phoenix.security/laravel-lang-composer-supply-chain-...
tonymet 4mo ago
Npm developers can relate to Windows being a target because it’s the most popular package manager. Why would you target xyz pkg niche manager knowing that only 200 people will install them? NPM does perform active offline & online vuln scanning on the packages. Everyone can do more, but they are going to be the #1 target.
xena 4mo ago
Ask and you shall receive: https://xeiaso.net/shitposts/no-way-to-prevent-this/supply-chain/2026-redhat-javascript-clients/ https://xeiaso.net/shitposts/no-way-to-prevent-this/supply-c...
EGreg 4mo ago
https://qbix.com/blog/2026/04/01/no-way-to-prevent-this-says-only-industry-where-this-regularly-happens-3/ https://qbix.com/blog/2026/04/01/no-way-to-prevent-this-says...

by jofzar 4mo ago

matheusmoreira 4mo ago

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 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
  I didn’t take it that way at all - rather, Arch is the only one that does it “right” with the AUR.
  - nailer 4mo ago
    If you want a usable system, you enable AUR. It's not 'doing it right', it's avoiding responsibility.
    - antiframe 4mo 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 4mo ago
      It's putting the responsibility on the party most capable and interested in evaluating the packages for security.
- matheusmoreira 4mo 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 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
Nix enters the room. (Everyone claps.)
myaccountonhn 4mo 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 4mo ago
IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable
- matheusmoreira 4mo 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_ 4mo 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...

chuckadams 4mo ago

The big attacks of today are spread across several package ecosystems: TrapDoor and Shai-Hulud have been hitting npm, pypi, composer, and crates with the same malware.

throwwwll 4mo ago
And all of them "thought" of security as an after-after-after-after-after-thought.
- deleted 4mo ago
  [deleted]
- freakynit 4mo ago
  Most of these are now building upon techniques that have already been exploited since past 1 years. This attack used 4 of those techniques. 1. Lifecycle Hook Execution 2. CI/CD Identity Plane Attacks 3. Maintainer Account Takeover and Malicious Publish 4. Self-Replicating npm Worms https://npm-supply-chain-attack-techniques.pagey.site/ https://npm-supply-chain-attack-techniques.pagey.site/
  - throwwwll 4mo ago
    Regardless of what these attacks exploit, see elsewhere a larping comment of mine: the solution exists, the implementation already mitigated numerous such and other exploits (it's nice to read "nix is not affected" on discourse or over matrix chat), it predates Docker by a decade, and is older than Ubuntu and Fedora (to give the perspective), yet people prefer to remain ignorant.
    - zitterbewegung 4mo ago
      You can have a security solution but with large ecosystems like this it can’t be pushed to the ecosystem immediately and everyone will take longer to test and deploy. Right now you could audit packages and make sure you don’t get the latest version

ajross 4mo ago

PyPI and Cargo are, 100%, vulnerable to this same class of compromises. That NPM sucks isn't a statement that everyone else doesn't.

kalcode 4mo ago

People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.

Defletter 4mo ago
The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.
- kalcode 4mo ago
  That's a good point. For me it's getting people to realize they need to take up practice that help minimize these things. It's kinda us and them problem. We need to ensure we don't just blindly install the latest, patch every CVE by just bumping everything to the latest even if the vulnerability has nothing to do with their system or use of said library. We should have rules that we install the latest that's older than three days. We should be running "npm audit" and other stuff like Trivy. The three day rule alone could save most people.
  - thaumasiotes 4mo ago
    > The three day rule alone could save most people. The three day 'rule' is just you hoping that someone else does some free work for you. If it is adopted by everyone, it has zero effect. We need rules that still work if people follow them.
    - deleted 4mo ago
      [deleted]
- Kuinox 4mo ago
  nuget have targets, and allow to run code on build, it doesn't have this problem because there is less dependencies.

Someone1234 4mo ago

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of other security settings, like minimum age, no trust downgrade, etc etc. All attackers can attack packages by updating how a package functions; but npm is particularly problematic as it runs non-sandbox scripts as the calling user. Putting not just your project at risk, but your entire machine/network. And this stuff has been known about for YEARS, they've taken no action.

dns_snek 4mo ago
> since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. This is semi-common and in no way unique to NPM.
- Ajedi32 4mo ago
  And even in the ones that don't, having to wait until the project executes to begin its attack is a minor inconvenience for malware.
- an0malous 4mo ago
  What other package managers do this? I don’t think Ruby does
  - matheusmoreira 4mo ago
    https://docs.ruby-lang.org/en//master/Gem.html#method-c-post_install https://docs.ruby-lang.org/en//master/Gem.html#method-c-post...
  - IshKebab 4mo ago
    Python does too I believe. Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly. The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it obviously.

TZubiri 4mo ago

tbf this is happening with a lot of package managers now, including pypi and composer

deleted 4mo ago

[deleted]

junon 4mo ago

Please stop posting this on every single security incident thread with npm. It was funny once, it's just rehashing the same debate over and over.

da_chicken 4mo ago
On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.
chipdale 4mo ago
Why should they stop? Maybe they want to rehash the issue that's not being adequately addressed. Maybe it's not supposed to be funny. How do you propose we address this issue? Instead of policing what people say, are you interested in sharing your or someone else ideas?
- junon 4mo ago
  It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.
  - moi2388 4mo ago
    [flagged]
    - junon 4mo ago
      HN has guidelines about curious discussion. Read them.
rectang 4mo ago
Opponents of gun control surely feel the same way about the Onion’s story.

nailer 4mo ago

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't allow scripts, but exploits happen everywhere.

m4rtink 4mo ago
If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution. Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack. Definitely not bulletproof but still IMHO more robust than "Lets just spray latest code from upstream without any review directly to production with a firehose!" that seems to be the norm.
- cozzyd 4mo ago
  Yes and typically updates take a while to be deployed...
- isityettime 4mo ago
  Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it. But there are norms in the distro about what those scripts are for and how to use them, and there's some social enforcement around that. The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of the social enforcement mechanisms are there and the companies behind the products I just mentioned all have histories of abusing them. That's why it's generally better to use Flatpak for things like that if your distro itself doesn't include them.
  - nailer 4mo ago

latexr 4mo ago

There’s actually a blog post with that exact title. https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://news.ycombinator.com/item?id=48155690 https://news.ycombinator.com/item?id=48155690

paulddraper 4mo ago

Last 30 days: PyPI, May 11. [1] Crates.io, May 22 [2] Composer, May 22 [3] [1] https://www.tenable.com/blog/mini-shai-hulud-frequently-asked-questions https://www.tenable.com/blog/mini-shai-hulud-frequently-aske... [2] https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-crates https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra... [3] https://phoenix.security/laravel-lang-composer-supply-chain-compromise-rce-backdoor/ https://phoenix.security/laravel-lang-composer-supply-chain-...

tonymet 4mo ago

Npm developers can relate to Windows being a target because it’s the most popular package manager. Why would you target xyz pkg niche manager knowing that only 200 people will install them? NPM does perform active offline & online vuln scanning on the packages. Everyone can do more, but they are going to be the #1 target.

xena 4mo ago

Ask and you shall receive: https://xeiaso.net/shitposts/no-way-to-prevent-this/supply-chain/2026-redhat-javascript-clients/ https://xeiaso.net/shitposts/no-way-to-prevent-this/supply-c...

EGreg 4mo ago

https://qbix.com/blog/2026/04/01/no-way-to-prevent-this-says-only-industry-where-this-regularly-happens-3/ https://qbix.com/blog/2026/04/01/no-way-to-prevent-this-says...