Live data from Hacker News

'No way to prevent this,' says only package manager where this regularly happens

kevinpatel.xyz

151–160 of 230 posts

Re: 'No way to prevent this,' says only package manager where this regularly happens

#152
post #107

Ah yes, only `npm` has ever suffered an attack. Ever. RubyGems: https://www.sonatype.com/blog/anatomy-of-the-rubygems-rest-c... PyPi: literally the latest attack included publishing malicious packages on PyPi XZ Tools, a part of nearly every Linux distribution nearly merged in code to backdoor SSH: https://www.akamai.com/blog/security-research/critical-linux... It is just easy pickings to blame npm specifically. Yes,…

XZ attacker spent half a year earning trust, doing real maintenance.

Different order of magnitude effort spent during XZ attack.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#153

Earlier quoted context omitted.

It's not defense in depth if the mechanism is trivially bypassed.

Trivial relative to which perspective? The distinction matters enough to care. Just because your father might give away their phone pin over the phone doesn't mean we should allow this granting remote access to his phone.

Trivial in the sense that in 99.9% of situations, "npm install" is immediately followed by "npm run", "npm test", or some form of execution. Any execution that imports a dependency is enough for a transitive dependency to execute its malicious payload immediately.

Post-install scripts have a slight edge over executing malicious code on import, i.e. they work 99.95% of the time instead of 99.9% of the time, but removing these scripts wouldn't materially change the situation we're in. You're locking the back door but leaving the front door and all of the windows wide open.

I'm going to suggest that we might be worse off in the short-medium term if post-install scripts are removed because everyone who thought that disabling post-install scripts was a "good enough" standalone security strategy will get caught with their pants down as attackers modify their payloads.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#155
post #82

Earlier quoted context omitted.

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…

> Enforce scope (namespace) requirement, and require external verification (reverse DNS for example). Who the heck says everyone who publishes a library has a domain? That seems absurd.

You can get subdomains for free from a number of places, some of which are more reliable than others.

This exists because domains (historically) used to be expensive by western standards. .com used to be $75/year back in the day.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#156

Earlier quoted context omitted.

It is 100% up to the package manager's steward to control how ownership of packages and namespaces are granted. Maven Central exists for decades the amount of incidents of people stealing namespaces is minimal. One can't simply publish a package under the groupId "com.ycombinator" without having some way to verify that they own the domain ycombinator.com. Then, once a package is published, it is 100% immutable, even…

Also.... Maven doesn't have "preinstall, install, post install", or " build.rs" for rust, executing arbitrary code during the installation. The code that's executing with Maven is in your pom.xml, not some hidden code from a transient dependency. That alone is a major design flaw in both npm and cargo. Java is boring, because it works. People don't like boring stuff. It's more exciting to play the Russian roulette on…

As a heavy user of Java I can assure you that Java is very very far from boring, especially when building it with maven or gradle. There are millions ways something can screw up the build. Rust (and Go too) in comparison is much more boring actually - it maybe I was just lucky, but the majority of stuff just builds with zero issues.

Especially the number of times I had to clean all the caches in order for maven and gradle to build the project is just far too high for me. It shouldn’t ever be needed if an ecosystem is meant to be considered boring. I feel like Java doesn’t build when I look at it wrong.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#158
post #77

It's a cultural issue, always feeling the urge to update to the newest possible package for things that are already working fine, without even reading the changelog to see if it's applicable. Cooldowns are only a way to force a bit of patience onto the maintainers... and they work.

If you have some sort of compliance requirements, you need to update because of the onslaught of CVE vulnerabilities in the older versions. They are mostly bogus like "regexp DOS" but you have to satisfy the process and update anyway.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#159

This link is clearly an AI laundered version of the long running joke from Xe Iaso. Shame. https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024... https://news.ycombinator.com/item?id=40438408

Both are parodies of The Onion's long-running series of articles.[0]

[0]: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

Re: 'No way to prevent this,' says only package manager where this regularly happens

#160

This link is clearly an AI laundered version of the long running joke from Xe Iaso. Shame. https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024... https://news.ycombinator.com/item?id=40438408

The form of wording goes back at least to 2014 in The Onion

https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

Post reply on HN