Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Package Managers need global hooks

captnemo.in

Post reply on HN
Print view View original

21–30 of 63 posts

Re: Package Managers need global hooks

#21

Post by tetha »

nightfly wrote: post #17
YuechenLi wrote: post #10

This seems to be primarily a problem with NPM, since it's the only package manager that I know of that allows for package authors to essentially run arbitrary post-install scripts silently package install. Shai Hulud/Mini Shai Hulud happened because of this obvious glaring hole in the system, they even had the script to download an official copy of Bun to spread itself in case the targeted machine has hardened their…

> since it's the only package manager that I know of that allows for package authors to essentially run arbitrary post-install scripts silently package install Are you sure? I'm pretty sure .deb and .rpm packages both allow that

Both certainly do. My own hypothesis on why this isn't a more widespread problem is the speed, or lack thereof, of these ecosystems. By the time a package hits debian stable, it's usually been under scrutiny for a year or more.

Re: Package Managers need global hooks

#22

Post by ozim » 

  Every package install is checked against the threat feed and it raises an exception if we find something malicious being installed
Ok big problem is lots of stuff installed for campaigns wasn't flagged in any feed. If maintainer access is taken over you still don't have any feed info, maybe it will be a bit faster to publish so if maintainer finds out.

Everyone is looking at NPM how bad it is or AUR lately. Those are "free for all anything can happen, any kid can publish" repositories and that's what you get.

No one looks at Debian and is saying "well maybe we should do what they do"...

Re: Package Managers need global hooks

#23

Post by jamesrom »

This is the opposite of "do one thing and do it well" unix philosophy.

You don't need your package manager to invoke your hook. You need _your_ tooling to invoke your hook.

./safely-bump-deps.sh && npm install

Want it global? Use a bash alias.

Re: Package Managers need global hooks

#24

Post by YuechenLi »

nightfly wrote: post #17
YuechenLi wrote: post #10

This seems to be primarily a problem with NPM, since it's the only package manager that I know of that allows for package authors to essentially run arbitrary post-install scripts silently package install. Shai Hulud/Mini Shai Hulud happened because of this obvious glaring hole in the system, they even had the script to download an official copy of Bun to spread itself in case the targeted machine has hardened their…

> since it's the only package manager that I know of that allows for package authors to essentially run arbitrary post-install scripts silently package install Are you sure? I'm pretty sure .deb and .rpm packages both allow that

>Are you sure? I'm pretty sure .deb and .rpm packages both allow that Learned something new today. Thanks.

I think the other significant issue with the NPM ecosystem that makes it bad in particular is NPM's dependency management is genuinely the worst out of any package manager because of phantom dependency is the default: you can be using a package without ever knowing that you are using it because it is imported implicitly, and the JS ecosystem dependency is so weird that taking down a small package that that a major project depends on cripples the entire JS ecosystem, as shown in left-pad, and launching a cyberattack via npm can be as easy as putting malicious code in any small package that large, popular packages depend on and watch it propagate. This is not hypothetical, it has been done, repeatedly in fact, over the years.

TS is a good programming language, however NPM is a security nightmare, and somehow the collective reaction of everyone depends on the JS/TS ecosystem seems like a shrug and "oh well, what can you do".

Re: Package Managers need global hooks

#25

Post by staticshock »

jamesrom wrote: post #23

This is the opposite of "do one thing and do it well" unix philosophy. You don't need your package manager to invoke your hook. You need _your_ tooling to invoke your hook. ./safely-bump-deps.sh && npm install Want it global? Use a bash alias.

Arguably, npm does one thing, but it does it poorly.

Re: Package Managers need global hooks

#26

Post by captn3m0 »

ozim wrote: post #22

Every package install is checked against the threat feed and it raises an exception if we find something malicious being installed Ok big problem is lots of stuff installed for campaigns wasn't flagged in any feed. If maintainer access is taken over you still don't have any feed info, maybe it will be a bit faster to publish so if maintainer finds out. Everyone is looking at NPM how bad it is or AUR lately. Those are…

Author here - people are definitely looking at other places. This just happens to be where the attacks are, and gets disproportionate attention as a result.

Do you have examples of campaigns that weren’t flagged? Everything except xz had a 1 day window and Dependency Cooldowns are super effective against most campaigns for that reason.

See papers at https://kokkonisd.github.io/ for eg.

Re: Package Managers need global hooks

#27

Post by captn3m0 »

jamesrom wrote: post #23

This is the opposite of "do one thing and do it well" unix philosophy. You don't need your package manager to invoke your hook. You need _your_ tooling to invoke your hook. ./safely-bump-deps.sh && npm install Want it global? Use a bash alias.

Aliases and pre-hooks are nowhere near the guarantees you want, that’s what I am arguing - not everything is invoked from a blessed shell. Safely-bump-does.sh is also impossibly hard to write because you are replicating _all of the work NPM does in transitive dependency resolution_. Unless you are re-generating the lock file from scratch - it isn’t safe. Just updating package.json isn’t sufficient for eg.

Re: Package Managers need global hooks

#29

Post by captn3m0 »

YuechenLi wrote: post #24
nightfly wrote: post #17

Earlier quoted context omitted.

> since it's the only package manager that I know of that allows for package authors to essentially run arbitrary post-install scripts silently package install Are you sure? I'm pretty sure .deb and .rpm packages both allow that

>Are you sure? I'm pretty sure .deb and .rpm packages both allow that Learned something new today. Thanks. I think the other significant issue with the NPM ecosystem that makes it bad in particular is NPM's dependency management is genuinely the worst out of any package manager because of phantom dependency is the default: you can be using a package without ever knowing that you are using it because it is imported im…

Package-level hooks are everywhere: https://github.com/ecosyste-ms/package-manager-hooks

I wrote this in response to the recent AUR attacks. The problem isn’t really too many dependencies - it is that most users cannot be auditing everything they install and we need mechanisms that help users where they are.

I audit my AUR pkg builds, and I would have likely caught any malware. But so would a Dependency Cooldown or a third-party threat feed. Package Managers should make it easy to build this tooling via hooks.

Re: Package Managers need global hooks

#30

Post by lelanthran »

weinzierl wrote: post #7
TZubiri wrote: post #6

Earlier quoted context omitted.

>Malware detection is hard Hell yeah >Write everything yourself, don't use third party No, you are exaggerating my point of view so that it's easier to dismiss and so you don't have to evaluate the proposition. A mix of a Strawman and a false dilemma. "Write more and use less third party, than you are currently using." would be more accurate. Consider this, the package manager I use has not been infected in over a de…

"Consider this, the package manager I use has not been infected in over a decade [..]" Which package manager do you mean?

>> "Consider this, the package manager I use has not been infected in over a decade [..]"

> Which package manager do you mean?

Apt, rpm.

Anyway, don't you think that this line:

> Which package manager do you mean?

Gives off "'No way to prevent this problem', says users of only package manager that has this problem" vibes?

Post reply on HN