Hacker News Reader

Comment by DotNetCorePowa | Hacker News Reader

You can thank the npm and the like.

Before, people were responsible for the dependencies they were importing.

With npm and all the javascripters flooding the market, it became normal to be irresponsible "because everybody is doing it".

Fast-forward a couple of years, now everything is web based, even the stand-alone app version. No one knows what is running on own computer, even the Devs themselves don't know what the are asking you to run...

With a pinch of vibe coding on top, and thats the end.

We took 40 years for our industry to be taken seriously, it's all gone now.

View on HN

Shared code repositories for OSS are much older than npm. See at least maven central for Java.

What makes npm a more relevant target is a much smaller standard library and thinner dependencies, leading to more chances that a random project will have code of suspicious provenance. The vast majority of what a backend Java project depends on was probably written either by the same 3 companies, or large, established OSS repos. So this is relatively solvable if people in steering committees decided they cared. It's improving, but I'd argue not fast enough.

Generally we don't hear much about attacks in Java like that. But they probably exist but python and javascript are targeted mainly because everyone uses them. They cover a lot of ground.

A big reason Python and Java are juicy targets are because for a very long time pip and npm executed code on the user's machine on package install, not just on import. (This is changing in newer versions of pip and npm IIRC)

I think it's mostly about attach surface. There is nothing fundamentally different in the threat model or security boundary between any language in terms of how they manage their dependencies. Even platforms like Maven or NuGet that don't have an install script, you're still likely to trigger a build or a quick run for the application right after installing that would trigger code execution anyway.

The chances of a person getting hit during the `npm install` phase is bigger but not that different than the `dotnet add package ... && dotnet run`.

I do agree though that the massive surface of npmjs, pip, and even cargo means that package signing is also not realistic. If you have the average 300 npm packages, no one is gonna pay attention to the authenticity of 200 different signing keys. It would be a lot easier with something like java where you probably just need to trust a handful like openjdk, jackson, junit, or log4j keys and be 90% there. (And hope the supply chain attack hasn't compromised the signing keys too of course)

The reason execution on install is a bigger deal than execution on import/run is because a lot of developers today run their code inside of sandboxed environments (containers, VMs, etc.) which prevents the malware from easily accessing stuff like session tokens.

not saying it's not possible to setup your environment that way, but in my experience, if you're installing outside a sandbox, you're also running outside a sandbox. I don't even follow the flow of installing packages outside said sandboxed environment being a container or VM and running inside it. People who use dev containers will have the entire toolchain in the dev container, and with VMs, while you could share the file system with something like virtio-fs or SMB/NFS, I don't understand the flow of `npm install` on the host then run in a VM. that sounds pretty awkward to me.

It's to make stuff like autocomplete or source browsing work in your IDE

I noticed this a lot with java where most of what I needed that wasn't specific to our company's business logic was already available in the standard library, and a lot of the OSS libraries I needed were relatively reputable and well-known. I did a few personal backend projects with js and the amount of functionality I had to crate-dig from npm drove me insane, on top of the more complicated chain of trust for how many layers packages from npm can have.

There’s also been a regression in how infrastructure is operated.

15 years ago you didn’t let your production infrastructure talk out to the Internet, and if you did, it was via an explicit proxy with allowlisted domains. This significantly limited the damage that a malicious dependency could cause.

With the move to cloud and DevOps, that network security model disappeared.

Cloud does let you do this with VPCs and subnets. Some people don't bother and end up susceptible but it remains best practice even for cloud software

It’s absolutely possible, but almost nobody does, at least until they get breached.

Developers have decided that the convenience of just letting their servers pull arbitrary code off the Internet is more important than the security risks.

> Before, people were responsible for the dependencies they were importing.

This is an attitude not reflective of reality for those that wrote code in the pre npm days

Yeah, and it isn't even a JavaScript thing either. The famous "import antigravity" strip from XKCD was about python.

The fact is we always were dependent on others.

I mean, I don't think the stereotypical JS and Python developer are all that different... at least when it comes to dependency management.

That XKCD comic is demonstrative of the opposite of what OP is talking about. Python and JavaScript are on opposite sides of the spectrum about what is included in the language and what is not. Python is “batteries included” which is why you can just “import antigravity” rather than “pip install antigravity”. JavaScript and NPM sit on the other end, where you have to infamously install the leftpad library to pad strings with spaces on their left, which left thousands of packages broken when it was taken off npm.

There's nothing new under the sun, as they say.

Perl had CPAN already in 1993; Linux and common BSD distros have basically always had package repositories.

"People were responsible for the dependencies they were importing" - I don't know about that. Plenty of us were irresponsible 30 years ago.

Don't know why you're getting scrutinized, npm didn't introduce malicious packages obviously but it did completely remove the feeling of suspicion and responsibility people had towards third party libraries.

The pre 2020 bootcampers would basically npm install anything because that's all they knew. You even had bullshit like "is-array" with millions of weekly installs because how dare you reinvent the wheel.

I just checked isarray got almost 300m installs in the past week.

L take. Can’t blame npm for software shops wanting to run leaner and ship faster.

I’m personally glad I don’t have to download separate runtimes and apps and can just use the standard browser

Except browser based versions take 10x the RAM of native versions.

Reply on news.ycombinator.com