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

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

kevinpatel.xyz

Post reply on HN
Print view View original

181–190 of 230 posts

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

#181

Post by apothegm »

saghm wrote: post #66
apothegm wrote: post #47

Earlier quoted context omitted.

Why Python, tho, in that case? Its stdlib is quite robust. Surprisingly so in some areas.

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…

I’m not suggesting pythons package management was good. This thread was started with a post about JS and Python, and I was responding to a message saying JS is so vulnerable to package repository attacks because its stdlib is so small. But Python’s been vulnerable too in spite of a robust stdlib.

And IMO the complaints about Python packaging tooling are overblown. Setuptools on its own was a bit disappointing, but coming from PHP 20 years ago it was a revelation! Virtualenvs and requirements.txt were an further improvement and so was pip — in an era where most other scripting languages didn’t have pinning for sub dependencies either; but you could always “pip freeze” to capture everything.

Later on, pipenv wasn’t perfect, but it was enough. I never ran into any of the headaches people keep saying poetry and uv solve. Poetry on the other hand always gives me one reason or another to beat my head against a wall.

That said, I’ve never bothered to try to publish anything and can’t comment on that end of it.

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

#182

Post by greatgib »

There is a good old time, before rust and go mindset ruined everything pushing people to wget|bash --install random crap on the spot, when experienced people used to rely on linux OS distributions like debian and co to source package and libraries and ensure to have "stable" and "safe" software procurement for professional and serious infrastructure and deployment.

But young blood mocked the fact to have to wait for Manual human review, safe gpg signatures, cool down periods and weeks of "testing" stage before being considered "stable".

And now most companies data are leaked and on the wide, hackers and ransomware are thriving...

This is crazy when you think about it because after so many years of software dev crafting experience, "modern safe" languages like go and rust, ..., typing, ... You would expect most software stack to be pretty solid and safe compare to 15 years ago.

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

#183

Post by Macha »

Gigachad wrote: post #17
exabrial wrote: post #10

I really don't understand why the npm project cannot embrace PGP as an ambulatory 'good enough' solution.

Would that help? Most of these recent attacks, the attackers have gained access to the system that builds the packages. So it would have just signed the malicious build the same.

In some ways the push towards trusted publishing has made these attacks more likely as the credentials are sitting in a standardized, always on CI system, rather than in a locked down corporate CI system for big packages or a developers machine or developers head for smaller open source packages.

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

#184

Post by Macha »

saghm wrote: post #71
exabrial wrote: post #10

I really don't understand why the npm project cannot embrace PGP as an ambulatory 'good enough' solution.

Probably the same reason that pretty much no other package manager (or even major email provider, when email is ostensibly the most famous use-case for it) has adopted it: the UX is atrocious.

Basically all Linux distro package managers?

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

#185

Post by Hackbraten »

eranation wrote: post #161
justsid wrote: post #144

Earlier quoted context omitted.

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)

But who will detect them on day one once everyone ignores them for seven days?

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

#186

Post by Hackbraten »

reshlo wrote: post #166
boredhedgehog wrote: post #147

Earlier quoted context omitted.

> 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.

Except that exhaustively scanning for badness is provably impossible.

It's inevitable that a false negative will slip through one day, and when that happens, it will compromise everyone who installs it, no matter if on day one or day eight.

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

#187

Post by arccy »

cookiengineer wrote: post #28
xena wrote: post #23

Earlier quoted context omitted.

go:generate is done at dev time, not at build time.

Actually bindings are usually generated like that, at build time (though with a build cache that nobody knows how it corrupts all the time). Examples that come to mind: webview/webview, webkit, cilium/ebpf and most other CGo projects that I have seen.

you only run them for your own project, not the generate directives of your dependencies though

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

#189

Post by jagged-chisel »

eranation wrote: post #64

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…

I'm not so sure cooldown would be effective. Someone still has to override the cooldown to install the (potentially) questionable releases and discover problems. If no one does, you've only delayed the problems by 3/7/10/14 days.

After thinking more while typing this:

I think I'd agree we should indeed have a 10-day cooldown (i.e. don't install anything released in the last ten days.) I suppose I just don't think anyone should expect it to be the only mitigation.

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

#190

Post by Barbing »

bot403 wrote: post #168
Barbing wrote: post #149

Earlier quoted context omitted.

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

Nobody can expose themselves during the danger period

Dev enforces cooldown on users, not users deciding they want to be safer. Dev has extra step of ensuring they check their accounts every ~23hr indefinitely.

The simple cooldown scenario sees potentially thousands of downloads of a malicious package. The 24 hour developer delay scenario sees zero downloads during the same period.

Post reply on HN