Live data from Hacker News

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

111–120 of 308 posts

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

#111

Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else. When I build backend in flask or Django, I specifically type the…

It's no different anywhere else. I just downloaded jj (rust), it installed 470+ packages

When I downloaded wan2gp (python) it installed it install 211 packages.

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

#112

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.

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.

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

#113

Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else. When I build backend in flask or Django, I specifically type the…

this is one of the less talked about benefits of using bun

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

#114
post #90
post #17

Earlier quoted context omitted.

how hard would it be to say "upon first install, run do_sketchy_shit.sh to install requirements"?

rpm and dpkg both provide mechanisms to run scripts on user machines (usually used to configure users and groups on the user machine), so this aspect is not an NPM-specific. Rust has the same thing with build.rs (which is necessary to find shared C libraries for crates that link with them) so there is a legitimate need for this that would be hard to eliminate. Personally, I think the issue is that it is too easy to c…

rpm and dpkg generally install packages from established repos that vet maintainers. It's not much but having to get one or two other established package authors to vouch for you and having to have some community involvement before you can publish to distro repos is something.

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

#115

Earlier quoted context omitted.

I get this but then in practice the only actually valuable stuff on my computer is... the code and data in my dev containers. Everything else I can download off the Internet for free at any time.

No. Most valuable data on your system for a malware author is login cookies and saved auth tokens of various services.

Maybe keylogging for online services.

But it is true that work and personal machines have different threat vectors.

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

#116

As a hobbyist how do I stay protected and in the loop for breaches like this? I often follow guides that are popular and written by well-respected authors and I might be too flippant with installing dependencies trying to solve a pain point that has derailed my original project. Somewhat related, I also have a small homelab running local services and every now and then I try a new technology. occasionally I’ll build…

(1) Start by not using packages that have stupid dependencies

Any package that includes a CLI version in the library should have it's dev shamed. Usually that adds 10-20 packages. Those 2 things, a library that provides some functionality, and a CLI command that lets you use the library from the command line, SHOULD NEVER BE MIXED.

The library should be its own package without the bloat of the command line crap

(2) Choose low dependency packages

Example: commander has no dependencies, minimist now has no dependencies. Some other command line parsers used to have 10-20 dependencies.

(3) Stop using packages when you can do it yourself in 1-2 lines of JS

You don't need a package to copy files. `fs.copyFileSync` will copy a file for. `fs.cpSync` will copy a tree, `child_process.spawn` will spawn a process. You don't need some package to do these things. There's plenty of other examples where you don't need a package.

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

#117

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 is a realistic solution.

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

#118
post #36

Earlier quoted context omitted.

No. I am literally describing bog standard use of an ordinary VCS/SCM where the code for e.g. Skia, sqlite, libpng, etc. is placed in a "third-party/" subdirectory. Except I'm deliberately using the words "admit" and "depository" here instead of "commit" and "repository" in keeping with the theme—of the widespread failure of people to use SCMs to manage the corresponding source code required to build their product/pr…

Does the lockfile not solve this?

not really, because you can't easily see what changed when you get a new version. When you check in the third_party repo to your VSC, then when you get a new version, everything that changed is easily visible `git diff` before you commit the new changes. With a lockfile, the only diff is the hash changed.

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

#119

As a hobbyist how do I stay protected and in the loop for breaches like this? I often follow guides that are popular and written by well-respected authors and I might be too flippant with installing dependencies trying to solve a pain point that has derailed my original project. Somewhat related, I also have a small homelab running local services and every now and then I try a new technology. occasionally I’ll build…

Somewhat controversial these days, but treat every single dependency as a potential security nightmare, source of bugs, problem that you will have to solve in the future. Use dependencies carefully and as a last resort. Vendoring dependencies (copying the package code into your project rather than using the package manager to manage it) can help - it won't stop a malicious package, but it will stop a package from tur…

Inspecting 10 layers of dependencies individually to install a popular tool or an lsp server is going to work once or twice. Eventually either complacency or fatigue sets in and the attacker wins.

I think we need a different solution that fixes the dependency bloat or puts more safeguards around package publishing.

The same goes for any other language with excessive third-party dependency requirements.

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

#120

Earlier quoted context omitted.

Does the lockfile not solve this?

not really, because you can't easily see what changed when you get a new version. When you check in the third_party repo to your VSC, then when you get a new version, everything that changed is easily visible `git diff` before you commit the new changes. With a lockfile, the only diff is the hash changed.

The problem is that not enough people care about reviewing dependencies’ code. Adding what they consider noise to the diff doesn’t help much (especially if what you end up diffing is actually build output).
Post reply on HN