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

941–950 of 1001 posts

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

#941

Post by Ygg2 »

ivan_gammel wrote: post #931
Ygg2 wrote: post #890

Earlier quoted context omitted.

> Standard libraries should include everything needed to interact with modern systems. So, databases? Which then begs the question, which - Postgres, MySQL, SQLite, MS SQL, etc.? And some NoSQL, because modern systems might need it. That basically means you need to pull in everything and the kitchen sink. And freeze it in time (because of backwards compatibility). HTML, HTTP parsing, and SHA1024 are perfectly reasona…

It is not madness. Java is a good example of rich and modular standard library. Some components of it are eventually deprecated and removed (e.g. Applets) and this process takes long enough. Its standard library does include good crypto and http client, database abstraction API (JDBC) which is implemented by database drivers etc.

Yeah, and Java was always corporately funded, and to my knowledge no one really used neither the http client nor the XML parser. You basically have a collection of dead weight libs, that people have to begrudgingly maintain.

Granted some (JDBC) more useful than the others. Although JDBC is more of an API and less of a library.

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

#942

Post by WorldMaker »

johnny22 wrote: post #720
WorldMaker wrote: post #297

Earlier quoted context omitted.

- I feel that you are unlikely to need Babel in 2025, most things it historically transpiled are Baseline Widely Available now (and most of the things it polyfilled weren't actually Babel's but brought in from other dependencies like core-js, which you probably don't need either in 2025). For the rest of the things it still transpiles (pretty much just JSX) there are cheaper/faster transpilers with fewer external dep…

Last i checked react's new compiler still depends on babel! :(

Yeah, I still don't understand a lot of the architecture choices behind the new compiler, including why the new compiler isn't mostly just a set of eslint suggestions with auto-fixes. I've seen the blog posts trying to explain it, but they don't seem to answer my questions. But then I also haven't done enough direct React work recently enough to have need of or actually tried to use the new compiler, so maybe I am just asking the wrong questions.

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

#943

Post by koakuma-chan »

ivan_gammel wrote: post #931
Ygg2 wrote: post #890

Earlier quoted context omitted.

> Standard libraries should include everything needed to interact with modern systems. So, databases? Which then begs the question, which - Postgres, MySQL, SQLite, MS SQL, etc.? And some NoSQL, because modern systems might need it. That basically means you need to pull in everything and the kitchen sink. And freeze it in time (because of backwards compatibility). HTML, HTTP parsing, and SHA1024 are perfectly reasona…

It is not madness. Java is a good example of rich and modular standard library. Some components of it are eventually deprecated and removed (e.g. Applets) and this process takes long enough. Its standard library does include good crypto and http client, database abstraction API (JDBC) which is implemented by database drivers etc.

My favourite is java.awt.Robot

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

#944

Post by petetnt »

The real key takeaway here is that Microsoft could fix this of they wanted: they have near infinite resources, the best people and more heavily invested in open source than anyone else in the business, but still refuse to even comment on the situation.

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

#945

Post by ivan_gammel »

Ygg2 wrote: post #941
ivan_gammel wrote: post #931

Earlier quoted context omitted.

It is not madness. Java is a good example of rich and modular standard library. Some components of it are eventually deprecated and removed (e.g. Applets) and this process takes long enough. Its standard library does include good crypto and http client, database abstraction API (JDBC) which is implemented by database drivers etc.

Yeah, and Java was always corporately funded, and to my knowledge no one really used neither the http client nor the XML parser. You basically have a collection of dead weight libs, that people have to begrudgingly maintain. Granted some (JDBC) more useful than the others. Although JDBC is more of an API and less of a library.

HttpClient is relatively new and getting HTTP/3 support next spring, so it’s certainly not falling into the dead weight category. You are probably confusing it with an older version from Java 1.1/1.4.

As for XML, JAXP was a common way to deal with it. Yes, there’s Xstream etc, but it doesn’t mean any of standard XML APIs are obsolete.

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

#946

Post by brazzy »

pjmlp wrote: post #936
999900000999 wrote: post #923

Earlier quoted context omitted.

It's not an easy problem to solve. Doing it the right way would create friction, developers might need to actually understand what the code is doing rather than pulling in random libraries. Try explaining to your CTO that development will slow down to verify the entire dependency chain. I'm more thinking C# or Java. If Microsoft or Oracle is providing a library you can hope it's safe. You *could* have a development e…

Why? This is a standard practice in most places I have worked, CI/CD only allowed to use internal repos, and libraries are only added after clearance.

Except that "clearance" invariably consists of bureaucratic rubber stamping and actually decreases security by making it harder and slower to fix newly discovered vulnerabilities.

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

#947

Post by pjmlp »

brazzy wrote: post #946
pjmlp wrote: post #936

Earlier quoted context omitted.

Why? This is a standard practice in most places I have worked, CI/CD only allowed to use internal repos, and libraries are only added after clearance.

Except that "clearance" invariably consists of bureaucratic rubber stamping and actually decreases security by making it harder and slower to fix newly discovered vulnerabilities.

Depends on the skills of the respective DevOps security team.

There are also tools that break CI/CD based on CVE reports from existing dependencies.

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

#948

Post by groby_b »

CaptainOfCoit wrote: post #888
silverliver wrote: post #871

Earlier quoted context omitted.

This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…

> External libraries are not for functionality that is used by most modern software. Where do you draw the line though? It seems like you mostly spend your time writing HTTP servers reading/writing JSON, but is that what everyone else also spends their time doing? You'll end up with a standard library weighing GBs, just because "most developers write HTTP servers", which doesn't sound like a better solution. I'm will…

> everything should be a library.

That's exactly npm's problem, though. What everybody is avoiding to say is that you need a concept of "trusted vendors". And, for the "OSS accelerates me" business crowd, that means paying for the stuff you use.

But who would want that when you're busy chasing "market fit".

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

#949

Post by pragma_x »

arccy wrote: post #837
pragma_x wrote: post #484

So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat. Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and acti…

Google has Assured Open Source for Python / Java https://cloud.google.com/security/products/assured-open-sour... Some other vendors do AI scanning I doubt anyone would want to touch js packages with manual review.

It would take labor, that's for sure. Manual review of everything JS is just too massive a landscape to cover. Automation is the way to go here, for sure.

I think the bare minimum is heavy use of auditjs (or Snyk, or anything else that works this way), and maybe a mandatory waiting period (2-4 weeks?) before allowing new packages in. That should help wave off the brunt of package churn and give auditjs enough time to catch up to new package vulnerabilities. The key is to not wait too long so folks can address CVE's in their software, but also not be 100% at the bleeding edge.

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

#950

Post by pragma_x »

tom1337 wrote: post #660
kilobaud wrote: post #497

Earlier quoted context omitted.

I've worked in companies that do this internally, e.g., managed pull-through caches implemented via tools like Artifactory, or home-grown "trusted supply chain" automation, i.e., policy enforcement during CI/CD prior to actually consuming a third-party dependency. But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving e…

How does a pull-through cache prevent this issue? Wouldn’t it also just pull the infected version from the upstream registry?

I think it's implied that packages can be blocked and/or evicted from said cache administratively. This deliberately breaks builds, and forces engineers to upgrade/downgrade away from bad packages as needed.
Post reply on HN