Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

socket.dev

Post reply on HN
Print view View original

451–460 of 1001 posts

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#451

Post by the8472 »

Liskni_si wrote: post #340
junon wrote: post #335

Earlier quoted context omitted.

Lock files wouldn't work if they were locking transitive dependencies; otherwise the version solver would not have any work to actually do and you'd have many, many versions of the same package rather than a few versions that satisfy all of the version range constraints. Lots of good ideas since last week, the one I like most being that published packages, especially those that are high in download count, don't actua…

In the Rust ecosystem, you only publish lock files for binary crates. So yeah then you get churn like https://github.com/cargo-bins/cargo-binstall/releases/tag/v1... bumping transitive deps, but this churn/noise doesn't exist for library crates - because the lock file isn't published for them.

lib crates have been checking in their Cargo.lock for a while now.

https://github.com/rust-lang/cargo/pull/12382

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#452

Post by weinzierl »

rlpb wrote: post #376
kirici wrote: post #351

Earlier quoted context omitted.

I'm using difftastic, it cuts down a whole lot of the noise https://difftastic.wilfred.me.uk/

This looks good! Unfortunately it looks like it also suffers from exactly the same software supply chain problem that we need to avoid in the first place: https://github.com/Wilfred/difftastic/blob/master/Cargo.lock Edit: also, consider how much of https://github.com/Wilfred/difftastic/commits/master/ is just noise in itself. 15k commits for a project that appears to only be about four years old.

"exactly the same software supply chain problem"

While the crates ecosystem is certainly not immune to supply chain attacks this over generalization is not justified.

There are several features that make crates.io more robust than npm. One of them is that vulnerable versions can be yanked without human intervention. Desperate comments from maintainers like this one[1] from just a few days ago would not happen with crates.io.

There are also features not provided by crates.io that make the situation better. For example you could very easily clone the repo and run

    cargo vet
to check how many of the packages had human audits. I'd done it if I was on a computer, but a quick glance at the Cargo.lock file makes me confident that you'd get a significant number.

[1] https://news.ycombinator.com/item?id=45170687

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#453

Post by 9dev »

dflock wrote: post #216
chrisweekly wrote: post #123

Earlier quoted context omitted.

Wait, what? "put the password store into a git repository"?!

The store in the case of pass, is a plain text file, whose contents are encrypted strings. If you trust the encryption, you can put it anywhere you like. Keep the keys secret and safe, though!

Until you have to fire one of your disgruntled employees, who has a copy of all your secrets that you now need to rotate.

A repository that an attacker only needs to get access to once, after which they can perform offline attacks against at their leisure.

A repository that contains the history of changed values, possibly making the latter easier, if you used the same encryption secret for rotated values.

This is an awful idea. Use a proper secret management tool you need to authenticate to using OIDC or Passkeys, and load secrets at runtime within the process. Everything else is dangerous.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#454

Post by IshKebab »

eschneider wrote: post #449
kelnos wrote: post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

If you pull something into your project, you're responsible for it working. Full stop. There are a lot of ways to manage/control dependencies. Pick something that works best for you, but be aware, due diligence, like maintenance is ultimately your responsibility.

That's very naive. We can do better than this.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#457

Post by zelphirkalt »

Ajedi32 wrote: post #420
gameman144 wrote: post #416

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

Most dependencies do much more than we need from them. Often it means we only need one or a few functions from them. This means one doesn't need to rewrite whole dependencies usually. Don't use dependencies for things you can trivially write yourself, and use them for cases where it would be too much work to write yourself.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#458

Post by [deleted] »

user3939382 wrote: post #182
progx wrote: post #121

Earlier quoted context omitted.

One downvote is not enough.

One upvote is not enough. We need enough upvotes to fix the problem. You can’t shape a big pile of shit into success. HTTP and JS will never serve as a proper application framework.

[deleted]

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#459

Post by kelnos »

orbital-decay wrote: post #244
cxr wrote: post #118

Earlier quoted context omitted.

It's not possible for a language to have an insane dependency tree. That's an attribute of a codebase.

Modern programming languages don't exist in a vacuum, they are tied to the existing codebase and libraries.

Sort of, but I don't really buy this argument. Someone could go and write the "missing JS stdlib" library that has no dependencies of its own. They could adopt release policies that reduce the risk of successful supply chain attacks. Other people could depend on it and not suffer deep dependency trees.

JS library authors in general could decide to write their own (or carefully copy-paste from libraries) utility functions for things rather than depend on a huge mess of packages. This isn't always a great path; obviously reinventing the wheel can come with its own problems.

So yes, I'd agree that the ecosystem encourages JS/TS developers to make use of the existing set of libraries and packages with deep dependency trees, but no one is holding a gun to anyone's head. There are other ways to do it.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#460

Post by IshKebab »

cycomanic wrote: post #446
Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

I've been arguing a couple of times that the 2 main reasons people want package management in languages are 1. Using an operating system with no package management 2. Poor developer discipline, i.e. developers always trying to use the latest version of a package. So now we have lots of poorly implemented language package managers, docker containers on top being used as another package management layer (even though th…

Nope. It's because:

1. You don't want to tie your software to the OS. Most people want their software to be cross-platform. Much better to have a language-specific package manager because I'm using the same language on every OS. And when I say "OS" here, I really mean OS or Linux distro, because Linux doesn't have one package manager.

2. OS package managers (where they even exist), have too high a bar of entry. Not only do you have to make a load of different packages for different OSes and distros, but you have to convince all of them to accept them. Waaay too much work for all but the largest projects.

You're probably going to say "Good! It would solve this problem!", but I don't think the solution to package security is to just make it so annoying nobody bothers. We can do better than that.

Post reply on HN