Remix.run Logo
▲ DotNetCorePowa 6 hours ago

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.

▲hibikir 5 hours ago | parent | next [-]

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.

▲ctkhn 4 hours ago | parent | next [-]

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.

▲hoppp 5 hours ago | parent | prev [-]

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.

▲td521534f12 4 hours ago | parent [-]

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)

▲eddythompson80 3 hours ago | parent [-]

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)

▲td521534f12 an hour ago | parent [-]

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.

▲bigfatkitten 2 hours ago | parent | prev | next [-]

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.

▲odo1242 2 hours ago | parent [-]

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

▲dpe82 5 hours ago | parent | prev | next [-]

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.

▲malfist 5 hours ago | parent | prev | next [-]

> 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

▲jbm 5 hours ago | parent [-]

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.

▲animal_spirits 5 hours ago | parent | next [-]

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.

▲lincon127 5 hours ago | parent | prev [-]

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

▲freecodeio 5 hours ago | parent | prev | next [-]

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.

▲arctek 4 hours ago | parent [-]

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

▲smashburger 5 hours ago | parent | prev [-]

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

▲UltraSane 5 hours ago | parent | next [-]

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

▲ 5 hours ago | parent | prev [-]
[deleted]