This truly has grown past a JS problem. NPM was kind of the first time dependencies were installed by the project rather than through the OS. But nowadays this has become the norm, golang, rust, and to an extent python also work by installing dependies directly from git for the most part. This isn’t going to get any better unless with revert to OS based dependencies which noone wants to do because developers want the latest and greatest model.
The way I see it, there are two problems with NPM:
It can blindly run any shell command w/o the developers explicit permission.
Anyone can make an NPM module, and the community is so fractured - common tools/features are not built into the language (or a standard library or a “vetted” community library - like boost for C++)
The first issue might be solvable with things like WebAssembly. Then it’s the developer who gets to decide how far these pm-hooks will reach (both interns of filesystem, network, etc) on a per project basis.
The second will need a shift in community mindset… and all these supply chain attacks are the fuel for that. Unfortunately, it needs to get worse before it’ll get better.
The first issue is NPM specific sure, but the second is true of all the languages I mentioned. Even golang which originally had a goal of having a built in library so vast you didn’t need much depencies has devolved into a large and fractured community.
I completely agree with you on the second point. This is a problem for all languages, but maybe we (as a community) need to change the approval, reviewing process for adding new libraries and features to languages.
This isn’t going to get any better unless we revert to OS based dependencies which noone wants to do because developers want the latest and greatest.
You’re very succinct here: Developer do want the latest and greatest, even if the interface isn’t perfect, and they’ll need to refactor their code when the next revision comes out.
Languages often have much slower release cycles than 3rd party libraries. Maybe this is what needs to be improved.
There won’t be a silver bullet, but I kinda like how kubernetes handles it: release cycles are fixed to a calendar (4 times per year). New features are added and versioned as alpha, beta, release. This gives the feature itself time to evolve and mature, while the rest of the release features are still stable.
If you use an alpha/beta feature, you accept that bugs and interface changes will occur before it reaches a stable release. … and you get warning and errors, if you’re using an alpha feature, but it graduated to beta/release.
Unfortunately, many languages either make this unnatural/difficult (ie: from future import… ) or really only support it if you’re using 3rd party libraries (use whatever@v1.2.3-alpha1).
Can’t they make dependencies something that get checked at launch time? The executable says “I have the following external dependencies pulled in. “ and then is a version is blacklisted, the executable should stop and throw an error saying exactly what component was blacklisted and stopped it from running.
Why can’t we have executable declare their dependencies at launch time to the OS?
That’s essentially how most distributions of Linux and Unix work. You package an app with a list of depencies like “libcaca >= 1.2.3” and that’s that. If that dependency isn’t available in the distro you need to have that packaged (and thus have a maintIner for said package) forst. The distro’s package maintainers are responsible for keeping an eye on the upstream sources and provide reviews. Then this sort of crap like NPM came along and it became popular for devs to package their own dependencies.
I’m not super familiar with Maven so I could be wrong, but doesn’t Maven still pull depencies from upstream? That doesn’t fix the problem. Having depencies packaged in the OS means there is in theory some level of overview and review by the package maintainer(s).
There are two reasons. One is the name spacing that is inherent in Maven and bolted on to npm, and the enforcement or lack of enforcement in the repository. You can read more about that here blog.sonatype.com/why-namespacing-matters-in-publ…
Then there’s the fact that npm runs “install” scripts when you download the component. This means if you can trick someone into grabbing your component by namespace confusion, typosquatting a name etc, you can get code run as soon as someone makes a mistake. Maven on the other hand only downloads the jars, it does not execute them.
Taken together, you have an easier path to tricking people to grabbing your component with npm and that trick leads directly to code execution.
I am on my phone, which is a bit too long to explain, but there are multiple facets to how NPM is worse than most packaging systems out there. There are enough on the web for you to browse and learn, if you are really interested to know more.
But, here, I quoted a little something from Brian from Sonatype.
This isn’t going to get any better unless we revert to OS based dependencies which noone wants to do because developers want the latest and greatest model.
A few operating systems (e.g. OpenBSD) do actually (try to) enforce using pkg for Perl dependencies, due to Perl being “system Perl” instead of “packaged Perl”.
wildbus8979@sh.itjust.works 13 hours ago
This truly has grown past a JS problem. NPM was kind of the first time dependencies were installed by the project rather than through the OS. But nowadays this has become the norm, golang, rust, and to an extent python also work by installing dependies directly from git for the most part. This isn’t going to get any better unless with revert to OS based dependencies which noone wants to do because developers want the latest and greatest model.
LedgeDrop@lemmy.zip 12 hours ago
The way I see it, there are two problems with NPM:
The first issue might be solvable with things like WebAssembly. Then it’s the developer who gets to decide how far these pm-hooks will reach (both interns of filesystem, network, etc) on a per project basis.
The second will need a shift in community mindset… and all these supply chain attacks are the fuel for that. Unfortunately, it needs to get worse before it’ll get better.
wildbus8979@sh.itjust.works 12 hours ago
The first issue is NPM specific sure, but the second is true of all the languages I mentioned. Even golang which originally had a goal of having a built in library so vast you didn’t need much depencies has devolved into a large and fractured community.
LedgeDrop@lemmy.zip 12 hours ago
I completely agree with you on the second point. This is a problem for all languages, but maybe we (as a community) need to change the approval, reviewing process for adding new libraries and features to languages.
You’re very succinct here: Developer do want the latest and greatest, even if the interface isn’t perfect, and they’ll need to refactor their code when the next revision comes out.
Languages often have much slower release cycles than 3rd party libraries. Maybe this is what needs to be improved.
There won’t be a silver bullet, but I kinda like how kubernetes handles it: release cycles are fixed to a calendar (4 times per year). New features are added and versioned as alpha, beta, release. This gives the feature itself time to evolve and mature, while the rest of the release features are still stable.
If you use an alpha/beta feature, you accept that bugs and interface changes will occur before it reaches a stable release. … and you get warning and errors, if you’re using an alpha feature, but it graduated to beta/release.
Unfortunately, many languages either make this unnatural/difficult (ie:
from future import…) or really only support it if you’re using 3rd party libraries (use whatever@v1.2.3-alpha1).muusemuuse@sh.itjust.works 8 hours ago
Can’t they make dependencies something that get checked at launch time? The executable says “I have the following external dependencies pulled in. “ and then is a version is blacklisted, the executable should stop and throw an error saying exactly what component was blacklisted and stopped it from running.
Why can’t we have executable declare their dependencies at launch time to the OS?
wildbus8979@sh.itjust.works 6 hours ago
That’s essentially how most distributions of Linux and Unix work. You package an app with a list of depencies like “libcaca >= 1.2.3” and that’s that. If that dependency isn’t available in the distro you need to have that packaged (and thus have a maintIner for said package) forst. The distro’s package maintainers are responsible for keeping an eye on the upstream sources and provide reviews. Then this sort of crap like NPM came along and it became popular for devs to package their own dependencies.
PushButton@lemmy.world 10 hours ago
Maven entered the room.
wildbus8979@sh.itjust.works 9 hours ago
I’m not super familiar with Maven so I could be wrong, but doesn’t Maven still pull depencies from upstream? That doesn’t fix the problem. Having depencies packaged in the OS means there is in theory some level of overview and review by the package maintainer(s).
PushButton@lemmy.world 9 hours ago
I am on my phone, which is a bit too long to explain, but there are multiple facets to how NPM is worse than most packaging systems out there. There are enough on the web for you to browse and learn, if you are really interested to know more.
But, here, I quoted a little something from Brian from Sonatype.
tux0r@feddit.org 11 hours ago
A few operating systems (e.g. OpenBSD) do actually (try to) enforce using
pkgfor Perl dependencies, due to Perl being “system Perl” instead of “packaged Perl”.wildbus8979@sh.itjust.works 11 hours ago
Debian does as well for anything that is packaged. For python, golang, rust, etc as well.