Do you trust NPM-based Typescript software?

🔃 Please boost for reach

We finally have the verdict. 117 people voted (I was hoping for more, but well, one have to work with what they have 😉

An absolute majority don't want to tie their security and privacy to software that are using npm.

So I think it is time to ask password managers to kindly start working on a client with less vulnerability to infamous npm issues. I'm not going to name any software now, but I do hope that FLOSS devs tame this matter seriously or explain what they are doing to mitigate this.

@Mehrad As long as it's not something security critical, and it's something like a game, it's fine

@Mehrad there is a large chasm between good and bad libraries on npm. I don’t think this question captures that nuance. Like anything you put in your software you should audit it yourself.

@CobyPear so when you update your computer, do you audit the whole supply chain and dependencies? Or do you only audit the main software and ignore all the libraries it internally uses? Because I don't think that any Linux distro has enough manpower to audit every library and package used in the software which they provide binary to. Or do they?

@Mehrad I trust the devs that pushed the update audited their dependencies and so on down the chain. Building software with npm and updating my computer’s OS seem very different to me, but i’ll bite; I would hope random libraries don’t get thrown into Linux distros but I’m fairly new to that scene so i’m sure it’s not as secure as i would think. What’s stopping a maintainer from saying “sorry we wont add this dependency because we can’t be sure it’s safe”?

@CobyPear there are two points of failure when it comes to a dependency:
1. When the package is used/added for the first time in a software (i.e name squatting, or already malicious/infected real package)
2. When a dependency gets an update (i.e possibility of potential malicious code change)

I personally think it is strongly unlikely that software devs track all changes of all their dependencies for each release. This get even worse when the software is "compiled" by the end user (e.g via AUR)


Yes, but that is besides the point. Many things belong to Microsoft (e.g Github, VSCode, WSL, bing), but just being owned by Microsoft doesn't necessarily made it bad (although all examples I could think of are 😅)

My point was that the npm dependency rabbit-hole can get pretty deep and no one would practically check all dependencies and their dependencies and ... in every single update. So we should be more vigilant when making software

@Mehrad Problem is it’s a binary poll for a complex & subtle problem

@feoh true, but remember that at the end of the day, if there is a firewall GUI or password manager or something security related, "do you trust it and install it"? At the end of the day, regardless of any discussion, the answer is binary: you either install it or not. 😉

@Mehrad @feoh been deliberately avoiding the NodeJS ecosystem for years at this point in part due to this exact reason. though to be fair, in bigger part because it's a whole nother giant mess I don't want to learn if I can help it (plus it's Javascript)

@deutrino @Mehrad Yeah. Same here. However I'm watching truly useful apps written using it proliferate. I guess a reasonable stance to take is: If you want to/need to use/build with that ecosystem, carefully vet the code you rely on, and you should probably be doing that anyway for ANY ecosystem, right? :)

@feoh @Mehrad I was sad to see that Misskey and another useful and conceptually simple app called Coindrop are based on Node.

I just don't have it in me right now to learn another highly complex ecosystem, especially one that embodies "move fast and break things" and whose dependency situation makes (for example) PyPI look like Debian by comparison

@Mehrad 100% agree. I think it's important to try to keep an open mind and fairly judge every piece of technology on its individual merits. I don't personally enjoy working in JS but lots of people do! 🤷

I don't think it is necessarily wise to trust any software without verification. The specific use case also matters as much as what it is intended for.

One problem with npm is how much interdependency exists. Modules depend on modules that depend on modules. Versions matter and it becomes nearly impossible to actually review the code pretty quickly. The thing you want pulled in 60 extra packages so reviewing one or two packages is no longer sufficient to build trust.

This is also a problem with things like pip and composer, and docker is a whole new level with layered builds making it even harder to identify what code is actually being executed.
Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.