Live data from Hacker News

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

301–308 of 308 posts

Re: NPM flooded with malicious packages downloaded more than 86k times

#301
post #11

Earlier quoted context omitted.

> As a hobbyist how do I stay protected and in the loop for breaches like this? For the case of general software, "Don't use node" would be my advice, and by extension any packaging backend without external audit and validation. PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe. The gold standard is Use The Software Debian Ships (Fedora is great too, arch is a bit down the ladd…

Didn't Debian ship a uniquely weak version of OpenSSL for years? HeartBleed perhaps? IME Debian is falling behind on security fixes.

And OpenBSD advertises "two remote holes in the default install, in a heck of a long time". And they're pretty serious about audits. It happens. But like the other comment said, this is about supply chain attacks via automatically executing code from live urls and not human fallibility.

Re: NPM flooded with malicious packages downloaded more than 86k times

#302

Earlier quoted context omitted.

Agree. It's going to take a lot of people getting pwned to change these attitudes though

Why would attitudes change? The impact is diffused across a wide enough populace (precisely because ecosystems with weak community norms around dependency security are extremely popular) that the rate of “shaping up in response to a painful lesson” may remain lower than the rate of newcomers joining the community or the rate of new insecure dependencies proliferating to serve new needs brought about by new use cases…

PHP is living proof that no matter how Broken As Designed something is, it will just go on if it's popular enough.

Re: NPM flooded with malicious packages downloaded more than 86k times

#303

Earlier quoted context omitted.

Don't do development on your local machine. Full stop. Just don't. Do development, all of it, inside VMs or containers, either local or remote. Use ephemeral credentials within said VMs, or use no credentials. For example, do all your git pulls on your laptop directly, or in a separate VM with a mounted volume that is then shared with the VM/containers where you are running dev tooling. This has the added benefit of…

That's not a realistic solution. Nobody is going to stop using their machine for development just to get some security gains, it's way too much of a pain to do that.

It's 100% realistic because *I've been doing it off-and-on for the last 25 years.*

When I was developing server software for Windows, the first time I was able to setup a development environment by simply cloning a VM instead of spending a day-and-a-half with a lap full of MSDN CDs/DVDs, I never went back.

Prior to that, I was happily net-booting *BSD/Solaris servers all over my house/apartment.

Nowadays, we have so many tools to make this trivial. Your contention doesn't stand up to basic scrutiny of the available data.

If you are downloading software from untrusted sources (e.g. NPM, pip, and others) and running it on your primary working machine, or personal machine, then you are simply begging for trouble.

Re: NPM flooded with malicious packages downloaded more than 86k times

#304

Earlier quoted context omitted.

That's not a realistic solution. Nobody is going to stop using their machine for development just to get some security gains, it's way too much of a pain to do that.

You are right, if it's a pain no one is going to do it. So the thing that needs to happen is to make it not a pain.

Wake up and smell the codespaces/workspaces/vagrant/so many other tools that make this not a pain. Some of these tools have been around for AGES. Nowadays, with VSCode Remote, you can even use a "modern" IDE environment with a local fat client observing your remote runtime. Other folks do this quite happily, with tremendous tooling, using emacs or *vim.

Re: NPM flooded with malicious packages downloaded more than 86k times

#305
These malicious npm packages often “phone home” during install or runtime, opening C2 channels, exfiltrating env vars, or beaconing quietly in the background. Static checks and SBOMs rarely catch that kind of dynamic behavior. With AI-generated or auto-installing code pipelines, that risk gets amplified since installs happen more often and less predictably. Watching what packages do at runtime feels like the next frontier here.

Re: NPM flooded with malicious packages downloaded more than 86k times

#306
post #129

Earlier quoted context omitted.

Yeah, people invented the concept of packages and package management because they couldn’t conceive of vendoring (which is weird considering basically all package managers make use of it themselves) and surely not because package management has actual benefits. Maybe in a perfect world, we’d all use a better VCS whose equivalent of submodules actually could do that job. We are not in that world yet.

Do you understand the reasons, and are you able to clearly articulate them? Are you able to describe the tangible benefits in the form of a set of falsifiable claims—without resorting to hand-waving or appeals to the perceived status quo or scoffing as if the reasons are self-evident and not in question or subject to scrutiny?

I'm not altogether surprised at the negative reaction to this comment, but I am at a loss to really get into the head of the reader who is so unhappy with it. Let's give it another shot:

You wrote—alluding to, but without actually stating—the reasons why registries and package managers for out-of-tree packages that subvert the base-level VCS were created:

> Yeah, people invented the concept of packages and package management because they couldn’t conceive of vendoring (which is weird considering basically all package managers make use of it themselves) and surely not because package management has actual benefits.

This is a sarcastic comment. It using irony to make the case that the aforementioned trio (packages, package managers, package registries), etc. were created for good reason (their "actual benefits").

Do you know what the reasons are? Can you reply here stating those reasons? Be explicit. Preferably, putting it into words in a way that can be tested (falsified)—like the way the claim, "We can reduce the size of our assets on $PROJECT_Z by storing the image data as PNG instead of raw bitmaps" is a claim that lends itself to being tested/falsified—and not just merely alluding to the good reasons for doing $X vs $Y.

What, specifically, are the reasons that make these out-of-tree, never-committed packages (and the associated infrastructure involving package registries, etc.) a good strategy? What problem does this solve? Again: please be specific. Can it be measured quantitatively?

Re: NPM flooded with malicious packages downloaded more than 86k times

#307
post #64

Earlier quoted context omitted.

What is "this"?

this = deps getting updated when you don't want or don't expect them to

We do not appear to have a shared understanding of the problem to be solved.

This is because you have redefined the problem—partly as a way of allowing you to avoid addressing it, and partly to allow you to speak of lockfiles as a solution to that problem. See https://news.ycombinator.com/item?id=45824392>.

Lockfiles do not solve the problem. They are the problem.

This is what I wrote:

> Overlay version control systems like NPM, Cargo, etc. and their harebrained schemes involving "lockfiles" to paper over their deficiencies have evidently totally destroyed […] folks' ability to conceive of just using an SCM like Git

That's the problem that I'm talking about—lockfiles. Or, more specifically: the insistence on practicing a form of version control (i.e. this style of dependency management that the current crop of package managers tell people is the Right Way to do things) that leads to the use of lockfiles—for the sole purpose of papering over the issues that were only introduced by this kind of package manager—and for people to be totally unaware of the water they're swimming in under this arrangement.

Everyone is familiar with the concept of "a solution in need of a problem". That's exactly what lockfiles are.

Re: NPM flooded with malicious packages downloaded more than 86k times

#308
post #53
post #7

Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "admit" the changes that have your approval, but it doesn't allow third parties to modify what's in your depository (even if it's a library that you're using that they wrote). When you build/deploy your program, you only compile/run third-party versions that hav…

So, vendoring?

That's a bingo.
Post reply on HN