Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

491–500 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#491
post #193

Earlier quoted context omitted.

That's the goal, but it's not feasible in e.g. professional settings. Much easier said than done, unfortunately.

I agree it's hard. But it's actually easier in professional settings. There are funds and you don't have an excuse to be lazy. At minimum whatever you are working on should be built in docker. The package installation then would happen during the image build step. Yes it's easy to break out of the isolation environment but i am betting this malware does not. NPM tokens should exist in some configuration/secret manage…

Docker is also not a silver bullet. Again, what you're claiming to be easy is often times exceedingly difficult or frictional, especially on established teams. I don't disagree that comparmentalization is important but security solutions are only as effective as their practical feasibility.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#492

Earlier quoted context omitted.

> Not sure why clap isn't std at this point. The std has stability promises, so it's prudent to not add things prematurely. Go has the official "flag" package as part of the stdlib, and it's so absolutely terrible that everyone uses pflag, cobra, or urfave/cli instead. Go's stdlib is a wonderful example of why you shouldn't add things willy-nilly to the stdlib since it's full of weird warts and things you simply shou…

Go is also famous for encouraging a culture of keeping down dependency count while exposing a simple to use package manager and ecosystem.

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... this article made the rounds here after the author pulled the thread on dependencies in Go

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#493
Seems to me the root problem here is poor security posture from the package maintainers. We need to start including information about publisher chain of custody into package meta data, that way we can recursively audit packages that don't have a secure deployment process.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#494
post #434

Earlier quoted context omitted.

> Because updates don't just include new features but also bug and security fixes. This practice needs to change, although it will be almost impossible to get a whole ecosystem to adopt. You shouldn’t have to take new features (and associated new problems) just to get bug fixes and security updates. They should be offered in parallel. We need to get comfortable again with parallel maintenance branches for each major…

Semver was invented to facilitate that. Only if everyone adhered to it.

> Semver was invented to facilitate that

First time I've heard that. How does semver facilitate backporting?

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#495
post #116

Earlier quoted context omitted.

No Preventative Measures (NPM)

You can host your own NPM reg, and examine every package, but your manager probably is NOT going to go for that.

Sounds like something a union should enforce as part of a drive to protect programmer professionalism.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#496

Earlier quoted context omitted.

2020 State of the Octoverse security report showed that .NET ecosystem has on average the lowest number of transitive dependencies. Big part of that is the breadth and depth of the BCL, standard libraries, and first party libraries.

The .NET ecosystem has been moving towards a higher number of dependencies since the introduction of .NET Core. Though many of them are still maintained by Microsoft.

The "SDK project model" did a lot to reduce that back down. They did break the BCL up into a lot of smaller packages to make .NET 4.x maintenance/compatibility easier, and if you are still supporting .NET 4.x (and/or .NET Standard), for whatever reason, your dependency list (esp. transitive dependencies) is huge, but if you are targeting .NET 5+ only that list shrinks back down and the BCL doesn't show up in your dependency lists again.

Even some of the Microsoft.* namespaces have properly moved into the BCL SDKs and no longer show up in dependency lists, even though Microsoft.* namespaces originally meant non-BCL first-party.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#497

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

Okay then, tell me a way to prevent this.

You have separate people called "maintainers", and they're the ones who build and upload packages to the repository. Crucially, they're not the people who write the software. You know, like Linux has been doing since forever. https://wiki.debian.org/DebianMaintainer Instead of treating your package repository like a trash can at a music festival, you can treat it more like a museum, curated by experts. Unfortunately, this isn't quite the devil-may-care attitude the Node ecosystem is so accustomed to, and will be met with a lot of whining, so it never happens. See y'all in two weeks when this happens again.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#498

Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…

Node and npm are not the same things. I'm not even a developer. You're seriously a developer?

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#499
post #457

Earlier quoted context omitted.

Everything runs in the container and cannot escape it. Its like a sandbox. You have to make sure you're not putting any secrets in the container environment.

You are just reducing the blast radius with use of podman; you will likely need secrets for your app to work, which will be exposed regardless of the podman approach.

[deleted]

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#500
post #202

There is no easy solution to these problems. The solutions that are effective also involve actually doing work, as developers, library authors, and package managers. But no, we want as much "convenience" as possible, so the issues continue. Developers and package authors should use a lockfile, pin their dependencies, be frugal about adding dependencies, and put any dependencies they do add through a basic inspection…

There absolutely is an easy solution to these problems, and Linux has been doing it forever: package maintainers. Don't treat your repository like a superfund site, and it won't fill up with garbage.
Post reply on HN