Live data from Hacker News

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

kevinpatel.xyz

161–170 of 230 posts

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

#161

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…

Doesn’t that just move the problem 7 days down the road? I always assumed these kinds of things just burn themselves because someone gets infected and realizes, not that there is an army of people auditing the changes. If everyone cooldowns for 7 days, it just happens later?

These get detected almost immediately, and removed by npm within hours (axios, tanstack at least)

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

#162

Earlier quoted context omitted.

This is like buying something from the grocery store and then waiting a week to eat it in case the FDA put out a warning about it.

More akin to letting astronauts stay in quarantine for a day in case they caught space bugs. If every other week I would notice the FDA recalls a popular brand that would have taken over my brain and transmit my bank password and SSN to a stranger, I might prefer drinking week old milk. Edit: not dismissing your analogy, it’s pretty much it.

If nobody drinks the milk until it’s a week old, that won’t help.

I do think cooldowns help, it’s more that this analogy doesn’t help.

The cow has to wake up and look at what milk she’s been putting out, and ideally the milk machine would use an early release channel so that some people will get the brain virus first.

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

#163
post #66

Earlier quoted context omitted.

I'm not convinced that Python should be the standard for package management either. Earlier this week I was trying to publish a Python package for the first time wrapping a Rust library I wrote (for use only on Linux and Python 3.12+), and it literally took me hours to get from "I have a wheel that I can import and it works on my system" to "I have published that wheel and can install the package from PyPI on the set…

> Python should be the standard for package management Python is the antistandard for package management. Or maybe even the eldritch horror of package management.

Curious if we included package managers from operating system distros (example: Debian apt), in your experience, what do you suggest JavaScript/Python/Rust package managers learn / borrow from?

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

#164

Earlier quoted context omitted.

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 g…

Yep, sounds boring!

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

#166

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…

> Why cooldowns? Most npm (or pypi) compromises were taken down within hours, But won't more people on cooldown mean less likelihood to catch the bug, thus extending the need for cooldowns?

These compromises are usually caught within hours by security researchers performing automated scanning of all published packages.

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

#167
post #119

Earlier quoted context omitted.

This is like buying something from the grocery store and then waiting a week to eat it in case the FDA put out a warning about it.

No it's not. That's a terrible analogy.

It's exactly the same. With both you have no idea if you'll be compromised once you pick up a new item from the store. With both you wait a week, in case the authorities issue a recall. With both you use it after that one week of waiting. Both are relying on luck to be safe.

The crazy thing is the risk from food is higher, we just don't really mind, because it's rare that we personally get affected

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

#168

Earlier quoted context omitted.

A large portion of the time, the maintainer notices what happened a few hours later. Maybe they were asleep or off doing other things for a while, but they eventually come back. And these kinds of takeovers frequently aren't complete enough to cover their tracks. So at the very least, adding a cooldown raises the difficulty of these attacks above that threshold.

Would be bad for software/progress I guess but, got me thinking of if we had an expectation a dev would post an update checksum/hash, then follow it up a day later with the update itself... (well maybe that leads to kidnappings idk) edit - heh, sibling comment on package manager-level must be much smarter

I fail to see how this isn't a simple cool down with more steps. It doesn't seem to add anything to the security posture of the package/update

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

#169

Earlier quoted context omitted.

Why don't you? It costs around $20 per year . Every serious computer nerd should have one, and a web server with at least a basic homepage.

$20 per year on US is not the same value across the world. Would you say $60 per year is ok too, if you adjusted for income? 100$? Don't count other people money.

The problem with this argument against, is that it reinforces the point it is arguing against: If a contributor cannot afford the $20/year to publish for a single 12-month period, then they are already a risk - someone could buy their account off them.

A small bar of $20/year is also enough to completely cut-down on contributors who sign up with the intention of publishing malicious packages: they have to pay $20/year for each malicious package they want to publish!

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

#170

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…

Honestly I'd prefer a system wide cooldown / age setting across all package managers and installers, with the option to poke holes / allow and also the option to deny / allow post installation runners. Something like a global asdf style installer that tracks and enforces these rules across all of it's managed package managers.

Something like a proxy that intercepts and depending on the source, is intelligent enough to examine the package for age. That would be cool. Already sounds like a cloud product you could sell.

Post reply on HN